In chapter one of Lea Verou’s excellent book CSS Secrets, she explains the standards process overseen by the W3C. An important point she makes is when she says:
It’s not (primarily) W3C staff that actually write the specifications … A widespread misconception … is that the W3C creates standards from up high that the poor browsers then have to follow, whether they like them or not.
She goes on to explain that browser vendors have a bigger voice in deciding what goes into standards than does the W3C.
So although there’s a lot in the web standards process that we might find troubling or even slow, we should keep in mind that, for the most part, standards aren’t created based on some kind of arbitrary experimentation or on a whim by individual power-hungry W3C members.
Pragmatism plays an important role and browser vendors will ultimately decide, through implementation and feedback, whether standards live or die. And evidence of this abounds. We’ve seen lots of standards that come as a result of paving the cowpaths.
For example:
- CSS variables are an obvious answer to the popularity of the same feature in CSS preprocessors.
- CSS’s “position: sticky” comes from who-knows-how-many jQuery plugins that have been doing the same thing for years.
- CSS animations are just a simplified syntax for stuff we’ve been doing with jQuery and other libraries.
- Transparency with images has been part of web page design long before CSS’s
opacityproperty or RGBA/HSLA. Those latter features were just a way to do this in a more maintainable manner.
I’m sure you can come up with other such examples where existing trends turned into standards, so feel free to let me know which standards you think are the most obvious examples of stuff we were doing by other means before those standards existed.
This editorial appears in this week’s issue of the SitePoint Front-end Newsletter
The new browser APIs that have come with the new HTML elements have been welcome. I’m looking forward to things like