Web Standards: We’re F’ing It Up

Post from May 18, 2015 (↻ June 8, 2021), filed under Web Development (feed).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

It’s a problem to just change specs. But it’s an increasingly bigger problem not to clean and prune them. The intimidating complexity of web standard specs should precisely be a motivation, not a threat, to come up with a plan. It follows the populist version.

We’re driving web standards—HTML and CSS and related specs ^*—against a wall because we only add, add, and add, and add, add, and add. And with all this unrestrained adding all our work and our professions are driven against a wall, too.

The situation is as complex as it is abstract. We face pressure to innovate and advance web standards—we want to innovate and advance web standards—, which means adding to them, and at the same time we cannot ever remove anything from a standard. In the words of Mark Pilgrim, “Standards are like sex; one mistake, and you’re stuck supporting it forever!”

When we must add but can never remove, things get increasingly, and rather exponentially than linearly, complex. We get a hunch for this in CSS, where we went from 53 to about 120 to far more than 300 properties.

That growth with all its opportunities is long known to be a problem: implementations become heavier, slower, and more error-prone, and code itself becomes more convoluted and complicated, for many web developers chase the latest and scramble for shortcuts, while few take the time to review and optimize techniques. For that reason, for example, have we variables in CSS, while most style sheets are WET.

Now, what helps us so far is inventiveness in other areas, like faster parsers and rendering engines which set off some of the weight on implementations, and abstractions like web frameworks that alleviate some poor coding practices. But these offsets are no cure; they fight symptoms, and will only float up developers who rather become experts in browser factoids or frameworks constraints than actually understand how e.g., browser reflows work or what makes for efficient code—for we’ve not studied that for everything. Or have never had the chance to do so.

Resting in the belief that this sufficiently describes our situation, what can we do? Although I worry about the future of quality HTML and CSS code because websites and apps are on a trajectory to become impossible to write “natively,” meaning without resorting to frameworks and libraries and such, I’m not sure what’s practical because of the conflicting needs as mentioned.

Our best options, but this is just meant to start a conversation and not as authoritative judgment, may be the, dare I say, versioning of standards, as well as clearer pronunciation of sites and apps. Both ideas are not new, and neither has been successful. We’ve pretty much decided to ignore standard versions and rather committed to living standards instead, and the idea of stricter differentiation between sites and apps may have been so obvious that it has never effectively registered.

The point, however, is that if we don’t get to streamline our standards, at least get the junk out of them, we face serious and then insurmountable limitations with respect to both implementations and code, to an extent that even abstractions will become pointless. Pointless in that websites shouldn’t need to be built using frameworks, libraries, variables, and be rendered by browsers that weigh >100 MB—something we still know now, but will forget. At that point, every browser may weigh a gigabyte, and most web developers don’t put HTML and CSS on their resumes, but Bootstrap and jQuery. And so let’s do something not to f this up completely.

Disclaimer: This is an opinion that’s playful rather than bulletproof. I’m At the time of writing this I was slowly deprioritizing my work in the web dev world and want to get some of my concerns out; get them out before I lost all interest in crying at the different standards friends and folk. Of whom this is no criticism by the way.

^* It’s actually not important here to discuss particular standards, for most maintained standards will suffer from the problem. If you must, and as I mostly follow these standards, peg the article to HTML and CSS.

About Me

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!