CSS, HTML, and the Problem of Spec Fragmentation

Published on December 5, 2013 (↻ February 5, 2024), filed under (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: 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:

  1. 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.

  2. 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).

  3. 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.

  4. 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 extremely 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.

Was this useful or interesting? Share (toot) this post, make a nano-donation, or support my work by learning with my ebooks.

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Be critical, interpret charitably, and give feedback.)

Comments (Closed)

  1. 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.

  2. On December 5, 2013, 23:46 CET, Ian Hickson said:

    The WHATWG FAQ, the HTML spec at the WHATWG, and other documents at the WHATWG, try to explain this stuff.

  3. On December 5, 2013, 23:53 CET, Jens Oliver Meiert said:

    qb, good point, I’ll look into rephrasing this section. We do have the “HTML for developers” and other documents which I’m referring to, too, and with “satellite specs” I’ve meant all the protocols, RFCs, and other documents that are important for the full picture (but this goes a bit far).

    Ian, I understand this to prove my point. Why is there not one complete, authoritative document that links to all relevant specs and allows a complete view at everything?

  4. On December 11, 2013, 9:46 CET, Leif Halvard Silli said:

    @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 …

  5. On December 12, 2013, 0:57 CET, Jens Oliver Meiert said:

    Leif, what do you mean by 2.?

    The “third party” idea is what I pick up from Tab as well. That would not be great from an authority standpoint but if there’s an option to move any resulting overview page under W3C/WHATWG control later, it may be worth trying. (I’m not sensing much interest in general, however, so I wonder whether it would even be on me to start something.)