This is my second post about Mozilla’s participation in the W3C’s Advisory Committee (see the first post).

There’s currently a review (ending May 12) of the Proposed Edited Recommendation of XHTML Modularization 1.1, Second Edition, produced by the XHTML 2 working group. This specification allows authors of DTDs and XML schema to make custom versions of HTML. To do that, it defines the syntax of HTML in terms of XML schema datatypes. These definitions are not necessarily compatible with other HTML specifications or with implementations of HTML.

We don’t see this specification as relevant to how browsers implement HTML or how Web authors writing content for the public Web write HTML. Its approach is not compatible with the approach in HTML5, and we intend to follow HTML5′s approach. Because of this, we have not followed its development closely, and we don’t see it as worth our time to gather a detailed list of objections that would be required to object to its advancement (as Björn Höhrmann did for some other specifications, which were rescinded).

Therefore, we chose to:

• abstain from the review, and
• check the box indicating that Mozilla “does not expect to produce or
  use products or content addressed by this specification”.

I wanted to start blogging about one of the ways Mozilla interacts with the W3C: reviews of charters and proposed recommendations in the Advisory Committee (which has one representative per W3C member company). Sometimes I find these somewhat awkward to write, since the W3C requires a single response on behalf of Mozilla. So I want to blog about these reviews to let the Mozilla community know how we’re interacting with the W3C and have the chance to provide feedback about that interaction. Additionally, I think blogging about these reviews provides some more visibility into the W3C process.

So I’ll start with the review of the Web Applications WG Charter, which closes today.

A working group charter defines what the working group is supposed to work on and what the group is allowed to work on. This charter is a rechartering of an existing working group that we participate in. The Web Applications Working Group is, along with the HTML and CSS working groups, one of core working groups for browser standards at W3C.
It’s responsible for designing and maintaining APIs that are not part of HTML and CSS, which includes things like the DOM and XMLHttpRequest, but now extends to many new technologies (see the charter for a full list).

Since the charter was already discussed and agreed on within the working group, we were already largely happy with the proposed charter. However, that doesn’t mean that we’re interested in everything in this charter. In particular, we’re not particularly interested in the widgets work going on in this working group, nor, because of the dangers of either relying on a single SQL implementation or trying to standardize an SQL dialect, in the SQL Database work. However, we don’t want to hold up the chartering process by objecting to these items being in the charter.

Therefore, our response said that:

• We:
  suggest changes to this Charter, but support the proposal whether or not the changes are adopted (your details below).
• Regarding the proposed revisions to section 3.1.2: we have a slight preference for the original over the revised version, but we are happy with either.
• We would also support dropping Web SQL Database from the charter; we don’t see how this specification will achieve two independent interoperable implementations.
• We:
  intend to participate in the Web Applications Working Group
• We:
  intend to review drafts as they are published and send comments,
  intend to develop experimental implementations and send experience reports,
  intend to develop products based on this work, and
  intend to apply this technology in our operations.
• We expect to implement (or have already implemented) many of the deliverables of this working group. We are not planning to implement the Web SQL Database, nor any of the Widgets specifications. (That’s not to say that we are planning to implement all of the rest, though.)

Let us define our terms. We already know that many of the really interesting native applications in the mobile space (written, for example, in Objective C) make use of web technologies, either using established web APIs from third-party providers (making use of HTTP and JSON or markup payloads) or using HTML and CSS for presentation. This is also true for applications on the desktop. For example, the iTunes Music Store uses a browser-based presentation layer. We are not talking about that kind of use of web technologies here. We are also not talking about widgets of any kind here. Those are web-like veneers, but not quite The Web as we have in browsers, with the same security considerations of an HTML page served up from a URL. What we are talking about here is web pages in a web browser. Are we safely evolving capabilities that these need, so that future applications can safely take advantage of these capabilities? Let’s take a look at a few of these capabilities, and how they fit in with the web page.

Before the advent of HTML5 File API, integration with the underlying file system was pretty primitive: you’d use the <input type="file" /> element in forms, and couldn’t really do much with the selected file. Now that Firefox 3.6 implements the File API, you can do stuff like asynchronously examine the EXIF content of an image, or the ID3 tags within an MP3 file. The asynchronous part is important — we don’t want a page to block on read operations, especially on the main thread. While there is the introduction of a new top level object (FileReader), the actual file is selected only by user interaction with the standard <input type="file"> element. DOM methods are used to access the selected file data from the file element. The resulting API integrates with the web page’s intrinsic element-based model, using the DOM to obtain a handle to the data, and asynchronous read operations on top of it. The new device capability is a natural extension of the web page model.

In addition to being able to access the device’s native file system, hardware acceleration for graphics is another important area for the web to take advantage of, especially with Graphical Processing Units (GPUs) becoming more sophisticated, and with driver support for OpenGL ES 2.0 become more prevalent. We’ve already seen really creative uses of the HTML5 Canvas2D drawing API on the web. The next task was to take the same HTML5 Canvas element, and provide interfaces to access hardware-accelerated 3D graphics. This is what WebGL does: it takes the same notion of providing an “immediate mode” drawing context made available to 2D graphics in JavaScript, and adds support for a 3D API (which closely resembles OpenGL ES 2.0, but with judicious concessions made for how the API would look like in a memory-managed language like JavaScript). Again, the goal is integration with the web. WebGL relies on the Canvas element (a part of the DOM), and provides interfaces to programmatically draw into the Canvas.

Both WebGL and the File API provide examples of integrating device capabilities with an existing HTML element. Other device capabilities also integrate with DOM Events, the event model for web pages. For instance, the HTML5 Drag and Drop API, which allows you to drag resources from your device to a web page, generates events that a web page can listen for, a model that web developers have been familiar with ever since the introduction of onclick back in JavaScript’s infancy. And then, there’s Orientation Events, supported in Firefox 3.6 (with a really compelling demo — try it on the MacBook Pro or the Nokia N900 and Fx 3.6). Every time you tilt or “orient” your device, the web page can listen to events and do something interesting accordingly. While the Orientation API isn’t yet a web standard, we’d welcome further discussion with other browser vendors about it. These device capabilities integrate with the web page’s event model, just as other device capabilities integrate with the HTML element structure.

The W3C Geolocation API is one device capability that isn’t integrated with the DOM of a page, or its event model. Rather, it is an extension to the navigator object, and provides an asynchronous API to get access to the device’s location, and (after user consent is obtained), provides that information back to the web page. It is now used by Twitter, Google Maps, and Flickr, to name a few (run these web applications on Firefox 3.6). This is an asynchronous API; user-consent is also obtained asynchronously, blocking the feature until the user grants consent. We posited some of these principles as general design guidelines for Device APIs just before the formation of the nascent W3C Device APIs WG, which we’re a tentative member of.

Web pages are becoming more and more capable, and some of the need for proprietary plugins can be obviated. When we consider further device capabilities, we’re really looking for:

• An asynchronous design
• Whether the new capability can integrate with a known HTML element as a starting point. We’re watching the evolution of the HTML5 <device> stuff pretty closely.
• Whether the new capability can integrate with the event model for web pages.
• And finally, whether we need a new top level object

We want the web of web pages and hyperlinked applications to be the platform of choice for developers, based on open standards and a well-understood security model. Whether this will eventually supplant native platforms is an open question, but talk of a web operating system is popular in some circles.

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.