We’ve just launched Firefox 3.5, and we’re incredibly proud. Naturally, we have engaged in plentiful Mozilla advocacy — this site is, amongst other things, a vehicle for showcasing the latest browser’s new capabilities. We like to think about this release as an upgrade for the whole World Wide Web, because of the new developer-facing features that have just been introduced into the web platform. When talking about some of the next generation standards, the appearance of the number “5″ is almost uncanny — consider HTML5 and ECMAScript 5 (PDF). The recent (and very welcome) hype around HTML5 in the press is what motivates this article. Let’s take a step back, and consider some of Mozilla’s web advocacy in the context of events leading up to the release of Firefox 3.5.

Standardization of many of these features often came after much spirited discussion, and we’re pleased to see the prominent placement of HTML5 as a key strategic initiative by major web development companies. Indeed, exciting new web applications hold a great deal of promise, and really showcase what the future of the web platform holds in store for aspiring developers. Many herald the triumphant arrival of the browser as the computer, an old theme that gets bolstered with the arrival of attractive HTML5 platform features that are implemented across Safari, Chrome, Opera, and of course, Firefox (with IE8 getting an honorable mention for having both some HTML5 features and some ECMAScript, 5th Edition features).

Call it what you will — Web 5.0, Open Web 5th Generation (wince!), or, (R)evolution # 5, the future is now. But lest anyone forget, HTML5 is not a completed standard yet, as the W3C was quick to point out. The editor doesn’t anticipate completion till 2010. The path taken from the start of what is now called HTML5 to the present-day era of (very welcome) hype has been a long one, and Mozilla has been part of the journey from the very beginning.

For one thing, we were there to point out, in no uncertain terms, that the W3C had perhaps lost its way. Exactly 5 summers ago (again, with that magic number!), it became evident that the W3C was no longer able to serve as sole custodian of the standards governing the open web of browser-based applications, so Mozilla, along with Opera, started the WHATWG. Of course, back then, we didn’t call it HTML5, and while Firefox itself made a splash in 2004, the steps taken towards standardization were definitive but tentative. Soon, other browser vendors joined us, and by the time the reconciliation with W3C occurred two years later, the innovations introduced into the web platform via the movement initiated by Mozilla had gained substantial momentum.

The net result is a specification that is not yet complete called “HTML5″ which is implemented piecemeal by most modern browsers. The features we choose to implement as an industry are in response to developers, and our modus operandi is (for the most part) in the open. Mozilla funds the HTML5 Validator, producing the first real HTML5 parser, which now drives W3C’s markup validation for HTML5. That parser has made its way back into Firefox. It’s important to note that capabilities that are of greatest interest (many of which are showcased on this blog) are not only developed within the HTML5 specification, but also as part of the W3C Geolocation WG, the Web Apps WG, and the CSS WG.

The release of Firefox 3.5, along with updates to other modern browsers, seems to declare that HTML5 has arrived. But with the foresight that comes with having been around this for a while, we also know that we have a lot of work ahead of us. For one thing, we’ve got to finish HTML5, or at least publish a subset of it that we all agree is ready for implementation, soon. We’ve also got to ensure that accessibility serves as an important design principle in the emerging web platform, and resolve sticky differences here. Also, an open standard does not an open platform make, as debates about web fonts and audio/video codecs show. We’ve got a lot of work ahead of us, but for now, 5 years after the summer we started the ball rolling, we’re enjoying the hype around (R)evolution Number 5.

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.

Now, standards are a big deal to us — everything we do here at Mozilla is, for the most part, a contribution to the Web platform. I blogged previously about the low esteem I reserve for arguments that favor proprietary platforms (which typically pit rapid proprietary innovation against dawdling Web Platform standardization cycles), but even in that upbeat blog post, I acknowledge that the standards process leaves much room for improvement.

My slides basically summarize the numerous places we go to build interoperable specifications, even though some of these places are theoretical at the moment (meaning we aren’t quite going there yet), and the activities we’re currently involved in. But, I was most interested in the audience participation part. That’s where I got to talk to folks working on stuff pertinent to standards, and to listen to their points of view.

Basically, many of the comments from the floor were in a plaintive vein. People love to air grouses about the standards process when given a chance. Some complained about having to read far too much email (on the W3C HTML5 WG listserv, for instance). I took a poll to see how many people followed HTML5’s progress exclusively on the WHATWG mailing lists, and how many people followed the progress of HTML5 on the W3C listserv. Slightly more hands went up showing a following of progress on the WHATWG listservs; a few people claimed to do both listservs. More than one person complained about the signal-to-noise ratio on the W3C HTML5 listserv, saying that there was a lot of cruft that burned up bandwidth and not enough really useful material to warrant the sifting. I tut-tutted sympathetically, but dealing with email isn’t just a standards involvement problem. I maintain that several were invited to W3C’s latest HTML party; few are experts. Some “topic sieve” mechanism for filtration is probably a good thing; there does seem to be relatively clean use of the email subject line, so developing a mail management strategy is really a mitigable problem (you’re on your own for that one, kids ).

Two general themes can be distilled from the open discussion we had:

• There continues to be the perception that W3C is too slow, especially given the rapidity with which Mozilla is moving. I asked an open question about where Robert O’Callahan’s cool SVG-in-CSS stuff should live. A modest amendment to the CSS charter? A W3C note? Or perhaps within the Compound Document Formats (CDF) WG? Naturally, we think it’s a great new capability to add to the Web platform — it’s an elegant stitching together of two standards, unleashed by an element id. Where should it live, though? How can it gradually become behavior that developers can count on? The pervasive sentiment was that the discussion of where it should live seemed prosaic, and that the time taken to even get it under way at W3C would be too long. The reasoning was that there would be a process impediment raised by those inimical to SVG or CSS doing things it doesn’t normally do (are there user agents that just don’t support SVG? Really?). WHATWG, however, just seems to get on with it. Maybe it was best off there?

  The argument that WHATWG moves much more rapidly than W3C is certainly true; WHATWG just doesn’t have closed door “Advisory Committee Review” sessions on charter amendments to deal with, and there isn’t really a lot of process overhead to getting a new idea put to text by a rapid editor. Even charter amendments to the successful W3C Web Applications WG would require an Advisory Committee Review cycle, which might result in lengthy discussions or a stalemate on controversial, “big patent” areas, like the Geolocation API, which will soon have its own working group. Who wants a stalemate? And few would venture that time spent waiting for a home for a new idea to live is time well spent, especially when you can just get on with it within the WHATWG.

• But every coin has a flip side. The big problem with the WHATWG is that Ian Hickson, its main editor (great guy) isn’t scalable (he’s mostly human, and this is a human failing). Plus, with one person as the gatekeeper of the important but floating HTML5 specification, disagreements are bound to arise. Those attending the summit did complain about changes to specifications that happened without their blessing — I heard terms like ninja insertions, and anecdotal stories about the rightness or wrongness of specification changes without a developer’s consent. For the most part, these dissipate with time — that’s just part of the process, which explicitly is NOT based on W3C-style consensus (by design). There’s a benevolent dictatorship at work here, which can be justified as being sound technically, but the fact of the matter is, you aren’t just dealing with an editor who puts in “majority rules” text. The editor is very, very opinionated. “Ninja insertions” in the specification can happen if you don’t monitor the email (which goes back to large cycles spent looking at email — just an occupational hazard, I suppose). Sure, WHATWG may be an imperfect system, someone pointed out, but it works and it’s fast.

So the two standards bodies which are of importance to Mozilla either have painful consensus building overheads or explicit legislation from the editor, both of which have pros and cons. Where’s the upbeat coda I promised, if there’s only problems and tricky nuances?

Actually, I took a poll of the audience to see who would be willing to edit specifications. The room was silent for a while, and then some of the usual suspects tentatively raised their hands. I’m upbeat not necessarily because I get to chase people up to do work and officially commit to documenting things for the Web Platform (which is great), but because of the number of people that attended my session, and because of the fact that as a community, we collectively spent an hour or so strategizing about future directions. The Web is a riotous assembly, too impatient for lengthy consensus cycles and too big to have a bottleneck of size one. We’ll work this out yet, and it will be imperfectly functional, with standards getting crafted in more than one place.