That there was controversy on the W3C Public HTML5 listserv shouldn’t surprise anybody. The future of the web platform attracts standards mavens and generally interested parties by the scores. January 2009 saw 694 messages exchanged on public-html@w3.org; some of them were ever so slightly laced with vitriol. Controversy is par for the course, as is spirited discussion that sometimes gets personal. On the subject of HTML5 (the markup and the APIs), even within Mozilla we aren’t necessarily unanimous about what’s good for the web, and what should be in the specification. Or how it should be written.

The topic this time around was intriguing. Mike Smith released a document called HTML5: The Markup Language. Should it be a normative specification, or merely an informative document? That is, should it help the Web Community by being one of the definitive references on HTML5 or should it merely be an informative document for people wishing to learn more? Also, who was the intended audience?

Soon after it was released, it was received with cautious optimism, but also some confusion. Was it for authors (who would write web pages), or for implementers of tools? Within the listserv, a debate raged. A markup specification devoid of parsing information, processing model and APIs was not useful or desirable, some argued, since invariably they were always used together on the Web. Moreover, making a single schema normative (as HTML5: The Markup Language initially did) prevented modification in the name of conformity. Mozilla posted what seemed like official positions to the listserv. Folks working on WebKit also stated their opinion that the document should not be normative.

At stake here was also what should be done about the larger HTML5 specification, formally called HTML5: A Vocabulary and Associated APIs for HTML and XHTML (but informally called The Kitchen Sink Spec., with affection and grudging respect, of course). How should the big specification be managed, and what should be done to modularize it? Could other editors work on parts of it, other than Ian Hickson? In the long term, was One Editor / One Spec. tenable? At least some suspicion about control issues must have existed, since not everyone’s goals were voiced in the open. And of course, there was the view that in order to be useful at all for some definition of “intended audience” HTML5: The Markup Language needed a bit more of the Kitchen Sink in it.

Such debates rapidly reveal two (or two-ish) camps. Although people working on Mozilla appeared to speak with authority on the matter of the specification, the fact of the matter is that at Mozilla, consensus isn’t unanimity. In general, we’re likely to question why an official response is being solicited on votes (and voting within the HTML5 working group is itself contentious). Naturally, modularizing a big specification such as HTML5: A Vocabulary and Associated APIs for HTML and XHTML is probably desirable. Note, for example, how long it takes your browser to load the Kitchen Sink Specification. Ian’s taken a crack at determining what could be split out, and some progress has been made on that front — Web Workers, for example, is now it’s own specification under the Web Applications Working Group.

HTML5: The Markup Language is a useful document, and makes for interesting reading. It’s status, however, remains controversial (normative or merely informative?). Time will tell, of course, how specifications bloom.

6 Responses to “On Letting Specifications Bloom…”

  1. Anne van Kesteren Says:

    For what it’s worth, Web Workers was never part of HTML5. XMLHttpRequest was.

  2. karl Says:

    Spring is coming around in the northern hemisphere, maybe it’s indeed time for blooming. :)

  3. Doug Schepers Says:

    Anne, he might have confused Web Workers with Web Sockets, which is also in the process of being split out into WebApps WG.

  4. Rigo Wenning Says:

    Unfortunately, some aspects may put some hair in the soup. W3C draws its renown and reputation from its process. One might hate the process, but it is W3C’s tool for vendor neutrality and impartial treatment of contributions. This process has roughly 2 options for documents: Recommendations and Notes. Recommendations are usually documents with mostly normative content, whatever that means. Notes are informative. Having the markup only informative would be a Note. But a Note can not superseed a Recommendation. So the result IMHO would be that HTML4 remains “normative”. I have trouble with the word “normative” for W3C as this term comes for the traditional “de-jure” standardization where there are different consequences attached to it. For whatever reason people do not want the markup NOT to be “normative”, it is a bad option also for systemic reasons. Again IMHO…

  5. aruner Says:

    Doug / Anne,

    Actually, I’m not confusing Web Workers and Web Sockets, but I am trivializing history. Sure, Web Workers was it’s *own* beast for a while, but then got moved to W3C (modulo the charter amendment decision by the W3C AC). So there’s the question of the AC vote on the Web Applications charter, and the charter amendment, which haven’t yet been resolved.

  6. | Cherish Says:

    [...] why their are conflicts between W3C and WHATWG on the development of HTML5. This is best said in this post by arun sir. Firefox 3.1 is actually supporting some of the HTML 5 elements like <video> [...]

Leave a Reply