Standards, not Prescriptions

a post on Development

Note: This is a rewrite of yesterday’s post. I wrote in haste last time, and in doing so was not very clear about certain points, and was off on others. Many thanks to Eric Meyer for being kind enough to correct me.

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.

First, Some Definitions

You can pay a visit to Merriam & Webster on your own time; I will not bother with their definitions here. Instead, I want to set out what I mean by a “Standard” and a “Prescription” for the duration of this post:


Standard
A normalized element, distilled from many solutions into a tried and tested ideal, in response to a well understood and familiar problem.
Prescription
A predetermined solution to a batch of symptoms. A prescription may not work the first time, therefore many must be tried until an equilibrium is found.

The Story Thus Far: Sense from Anarchy

When the web was young, browsers heavily influenced the fate of HTML, CSS, and Javascript by doing what(wg) was best for their products. They did mostly follow W3C guidelines (post 1995), but they also adopted many of their own solutions. The measly few web workers brave enough to be such a thing at that time 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, they 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. Personally, though, I would still prefer some of those vendor-specific solutions to what is in the current specs. In Javascript, IE’s attachEvent and currentStyle make much more sense than what has been defined in the specification (addEventListener and getPropertyValue(), respectively). In CSS, zoom is much more elegant to implement than transform: scale(); and coming from a print design background, I easily mapped b and i to bold and italic, though I stopped using them in favor of strong and em because at one time b and i were set to be deprecated (though not anymore), and are still treated as bastard step-children.

The Prescribed Web: Another Shade of Hell

Specifications reach too far when they become prescriptions. 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 long enough for a clear answer to climb its 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 added 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

I know that on some level, all of the web has been “prescribed”, but the second part of my definition of a standard is key: to create a standard we must first have a well defined problem, not symptoms. When we try to create standards for symptoms, we are prescribing. Most of the major advancements in the spec thus far have been responses to well understood problems. I do not mean that the people creating them were super-smart (though they probably were), and could therefore fathom the depths of what was needed. I mean that these problems had been around for a while, and therefore the facets of each issue were understood deeply by most involved.

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. With clever polyfills, shims, or even good old-fashioned Javascript, we have the ability to create solutions right now that work the way we see fit. jQuery, LESS and SASS are all examples of how syntax and behavior can be normalized and improved without being codified by the standards bodies, and how these solutions can eventually lead more informed specifications.

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, preprocessors, and hacks climb from the anarchic pits of everyday web work, though, we should simply wait.