Standards, not Prescriptions

a post on Development

17/05/2012 · Penarth, Wales · I honestly couldn’t tell you if srcset is better than picture. How could I? It hasn’t even been implemented by browsers, let alone tested in the wild. Yet across the web, torches have been set aflame and pitchforks brandished in support of srcset, or picture, or whatever else.

Let me make this clear: Standardization is a good thing. It has made the life of front-end developers/designers much less stressful. But we are in danger of going too far. We are beginning to prescribe the web, not standardize, and that path will only lead to more frustration, and ultimately stagnation.

The Story Thus Far: Order from Anarchy

When the web was young, browsers controlled the fate of HTML, CSS, and Javascript. No one told the browser makers what(wg) to do. They adopted their own solutions, and the measly few web workers brave enough would toil through the night to wedge their sites between compatibility with as many vendor methods as possible. It was hellish – it still is – but when the standardization movement swept through the land, we had a mountain of practical, tested solutions through which to sift. Standardistas carved, combined, and blasted with dynamite until only the best, most useful implementations where left (mostly), making hell just a bit smaller in the process.

Standardization was necessary, but also wildly successful precisely because of the anarchy of the early web. All of that energy, competition and confusion born from chaos generated hundreds of solutions for the myriad quirks found in that awkward new medium.

The Prescribed Web: Another Shade of Hell

Standardization goes too far when it becomes prescription. We have all seen this in our processes when prototyping sites or applications: prescriptions are often obliterated in testing. We know that thinking-then-doing is not a complete cycle. The addition of testing brings more informed and more practical results from a wider array contributors.

I applaud the efforts of the web’s standardizing bodies (W3C and WHATWG) thus far, but I fear they have begun prescribing solutions, rather than waiting for them to climb their way up from the community. This is backwards. srcset is one example, but a picture element would be prescriptive at this point, too. Most of the pro/con breakdowns I have seen have been argued by front-end developers, when such decisions will likely have an impact on design and most certainly on back-end products like CMSs. We cannot know which is best for all of these interests until we all use them, so how can one be codified into a spec over another at this time?

Another timely example is the addition of new units of measure, specifically vw and vh. These “viewport-percentage” lengths seem to try to solve responsive issues with measurement by giving the measure a relationship to the viewport width or height, but the language of the specification is so loose it leaves the actual browser implementation wide open. Will they be relative to the actual viewport, or a container? What is the use case for widths relative to a container that we can’t already solve with percentages? I don’t really know. Let’s give them, and maybe a few other ideas, a try on some real sites before we chisel them into the spec.

A prescribed web will result in specifications that break down in actual implementation, leading to more confusion and more hacks, which is what standardization was meant to solve in the first place. Prescription will not make the life of web workers simpler or easier.

The Only Prescription: More Anarchy, More Solutions

These latest specifications feel reactionary. Before we jump into syntax, lets make sure we are asking the right questions. srcset and picture are both trying to create a correlation between browser width and image size, but what about bandwidth? Does it matter that a small image is served to a mobile device with a broadband WiFi connection? Do we really want to send a high-res image to a laptop speeding along on a train, intermittantly connected to a 3G network? These wholly different questions on responsiveness and images lead me to develop Pngy: a simple script that tests download speed, then loads images accordingly. (In researching this post, I found two similar projects: Foresight and HiSRC. Give them a try!)

How would srcset or picture respond to a bandwidth problem? Given the time and impetus, a spec might be crafted, but the net cast to capture potential solutions will have been limited, and possibly riddled with needlessly political holes.

For standardization to truly continue making the web a more stable place, we do not need more anticipatory specifications, we need solutions. Lots of them. Dumb ones, fat ones, smart ones, skinny ones. Let us embrace them all then watch them fight it out in the field. When the strongest emerge, we can adopt them into our specs and wait for the next batch of victors. Until those battle-hardened scripts and hacks climb from the anarchic pits of everyday web work, though, we should simply wait.