Fragments of the Web

With Apple’s introduction of the Retina-display-equipped Macbook, we’re starting to enter a transitional period in display resolutions. As usual, Apple’s leading the charge while keeping things simple via pixel doubling, but much like Android and Windows 7/8, I anticipate that other vendors will exhaust all possible form factors and permutations.

With reviews coming in, the disclaimers are remiscient of when tablets and phones underwent the same display evolution: wait for the content updates to take advantage of the added pixels. For mobile devices, this naturally meant bigger app downloads with larger assets; for personal computing, a lot of the work will be upgrading the web to 2x.

For web developers, this is just the latest in a long line of enhancements under the HTML5 umbrella. That said, inconsistent support for the unratified spec is akin to the “best viewed in 800×600” footers of a prior decade; the bleeding edge of web development still requires targeting a specific browser[1], at an ideal resolution, with enough hardware juice to run animations, canvas drawings, and possibly WebGL-powered 3D renderings.

The browser is the common denominator across all computing platforms and the media talks about the web’s ubiquity and Java-esque “write once, run anywhere” ambitions, but reality is shaping out to be much less utopic. Even assuming full support of CSS3 and HTML5, with all the Javascript APIs ready and accessing available hardware components, there’s little guarantee that performance – at the JS interpreter, DOM, or network levels – will acceptably degrade for anything that is not a top-of-the-line desktop system on a high-speed connection. Intensive webapps like Gmail start to crumble when operating under limited resourced environments.

Meanwhile, the standard answer to screen resolution diversity has been responsive web design by using media queries to provide a superset of layout rules to accommodate all screen sizes. In practice, this strategy works well if the content can be laid out as distinct, independent columns: the slices stack on top of one another as the available width shrinks. Intricate and app-like designs, however, much harder to fix; an animation spanning the full page, a table or chart with useful horizontal data, or even just a handful of form fields with contextual hints to the side are fundamentally incompatible with small screen sizes. From experience, the UI is substantially different when moving from small to big screens (and vice versa), and the effort required is almost as much as building a new page housing the tweaked designs.

Fundamentally, the same site is not running on the same codebase across browser implementations; today’s websites and webapps contain hundreds of little branches and special exceptions hidden within a single codebase, whose parsing and execution will output code customized for each platform. For all the noise made about Android’s fragmentation problems, the web faces just as many, if not more, challenges. Sadly, the default response has been “we can’t justify spending our time supporting low usage clients”[2], even as the frontrunners continue to add proprietary new features and APIs.

As more browsers and browser versions become available, this scheme can’t be sustained, either from a maintainibilty or a scalability standpoint. I can’t pretend to have an answer, but recognition of the problem is a first step.