CSS, HTML, and the Problem of Spec Fragmentation
Post from December 5, 2013 (↻ June 29, 2017), filed under Web Development.
This and many other posts are also available as a pretty, well-behaved e-book: On Web Development.
We have not one but two fundamental problems with CSS. One is unrestricted growth and complexity leading to poor understanding and poor code. Another one is spec fragmentation, also an issue with HTML, which results in inefficiencies. We should look for a better balance.
How Are CSS and HTML Fragmented?
The idea with CSS 3 was to work with modules to get more done, that is, spec’ed and implemented, and that faster. That worked well—too well—as now we have dozens of modules spread out over the W3C site and, as if that’s not enough, even a few flocking on the WHATWG site. Not to speak of features that are specified in HTML, at least temporarily, and in SVG.
For HTML, there’s the WHATWG spec and the W3C spec, there’s HTML “5.1”, there are the dev versions, and there are documents like the developers edition. There are also all the different satellite specs for underlying and complementary standards that are, however, a bit unfair to point out here. While the situation with HTML is a bit different, it still suffers, in principle, from the same problems CSS suffers.
How Is Fragmentation a Problem?
First, I’m surprised that spec fragmentation does not appear to be an issue for implementors. From what I can tell in conversations with vendors and former colleagues, things seem to be working well. (Writing this I’m becoming more doubtful though as I do suspect implementor work more impaired than those conversations suggested.)
The problem is that spec fragmentation makes it harder for developers to access, understand, and work with specifications. Fragmentation is a barrier to effective use of the specs.
I’ve seen enough cases on developer mailing lists in which confusion set in as to either where to find a relevant spec, or which spec was applicable. If developers weren’t suggesting features that were already in the making in a hard to find location, that is. My favorite case, related to HTML, involved both spec confusion and unnecessary differences. W3C’s CSS overview pages, including the “current work” one, do neither offer complete access nor are they easy to understand, and for HTML there is no authoritative page at all that would list all relevant documents and explain why things are as they are.
What Can We Do?
We can tackle the problems by creating such authoritative overview pages, refactoring what we have, and looking into policy adjustments:
For CSS, complete the W3C’s main CSS overview page by including and maintaining a full list of all CSS specs, both at the W3C and elsewhere; that page should make the “current work” page obsolete.
For HTML, publish a similarly comprehensive list for all relevant specs on both the W3C’s main HTML page and the WHATWG’s spec page (that’s one price to pay for not agreeing with each other), alongside a brief explanation of how the WHATWG and W3C versions relate to each other (not everyone knows).
Make an effort to reduce the number of current specs and modules to a workable minimum. We do not want—nor do we need—to go all the way as we’ve already made our experience with monolithic specs, but there is a better balance in how we can do spec work and still make it easy for developers to access and understand the specs.
Consider establishing principles around the desired granularity and complexity of specifications so that spec authors enjoy more guidance and that other parties, like implementors and developers, find more transparency in terms of how the specs are designed. Specs like CSS and HTML are too complex not to come with a clear policy that prevents overshooting in any direction.
The point is this: Both CSS and HTML have become very complex, and we shouldn’t add to the complexity by splitting the specs up into overly many pieces. That just makes CSS and HTML harder to understand both individually and as a whole, and stands in the way of the specs’ success in terms of being used more effectively.
I’m Jens Oliver Meiert, and I’m a web developer and author. I love trying things, including in the fields of philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have any suggestions or questions about what I write, leave a comment or a message.
On December 5, 2013, 23:16 CET, qb said:
I don’t think you’re making the case that HTML is too fragmented very well. You’ve basically listed just two standards: WHATWG and W3C. While there is supplementary material for both, and W3C has another ‘version’ in development, those two ‘main’ specifications amount to the current state of HTML. As they don’t show any sign of reconciling, and each group is just going to recommend their side, I don’t think anything further can be done except explaining the difference to newcomers.
The WHATWG FAQ, the HTML spec at the WHATWG, and other documents at the WHATWG, try to explain this stuff.
@Jens O. Meiert:
Why is there not one complete, authoritative document that links to all relevant specs and allows a complete view at everything?
Perhaps because …
1. it would mean extra work.
2. a document like that by necessity would not become an “authoritative document“.
3. it would end up with many parallel but, from a practical point of view, largely identical sections.
4. it would end up rather confusing, with many sections that would have to be labeled ”this is not valid, if you wear WHATWG glasses“ etc.
6. it seems both specs (and the process behind them) play a role in both camps
May be such a document should/could/must eventually be produced by a third force …
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out some of the most important aspects of such CSS. (Also available in a bundle with Upgrade Your HTML.)
Looking for a way to comment? Comments have been disabled, unfortunately.