Standards, not Prescriptions
a post on Development
Note: This is an 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
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:
- A normalized element, distilled from many solutions into a tried and tested ideal, in response to a well understood and familiar problem.
- 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
currentStyle make much more sense than what has been defined in the specification (
getPropertyValue(), respectively). In CSS,
zoom is much more elegant to implement than
transform: scale(); and coming from a print design background, I easily mapped
i to bold and italic, though I stopped using them in favor of
em because at one time
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
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.
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!)
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.