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.

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.

I’m admittedly being a bit glib in my title. Can innovation and advancement of the web platform occur at all, given the temporal straight jacket that standards bodies sometimes impose? There are certainly proprietary platforms that leverage the web (Flash and Silverlight) and developers do happily bivouac in them, building some fairly compelling stuff. Some even argue that these proprietary platforms push the envelope more than what the web can do by itself, given the stagnancy of standards bodies.

But let’s talk about the web platform. Stagnant, really? Innovation at Mozilla ultimately manifests itself as innovation for the web platform. Let’s leave the intricacies of the standards process for another discussion — it isn’t ideal, and big questions about consortia (like W3C and ECMA) are probably valid ones. Great ideas are vetted for interoperability in forums such as the WHATWG, and the W3C’s WebApps WG, and we browser vendors deliver as rapidly as feasible on implementations (some are slower than others — you know who you are). Both IE8 Beta and Firefox 3 now support postMessage, for example, so talk of AJAX methodologies being stagnant ought to be revisited. And support of Canvas2D in browsers such as Opera, Safari, and Firefox results in stellar innovations such as processing.js, which — any “open platform” chauvinism on my part notwithstanding — gives Flash a royal run for its money.

Mozilla’s involvement in standards encompasses enhancements to JavaScript, graphics, and APIs for new capabilities. Below is a breakdown of the work that will eventually be a part of the web platform. Don’t stop and stare for too long — there is nothing stagnating here

• Evolving the AJAX backbone essentially means adding new capabilities to the XMLHttpRequest object, which is really the skinny man on stilts behind the AJAX wizard. Currently, the XMLHttpRequest object (abbreviated XHR) can’t cross the single domain threshold, but we’re working on a “mitigation” mechanism to allow cross-domain access called Access Control, which will be used by API containers such as XHR Level 2. Allowing Cookies and HTTP-Authentication mechanisms for safer cross-domain mashups is controversial, certainly, and safety is paramount. Amongst the topics to consider are interoperability with Microsoft’s equally controversial XDomainRequest object, introduced in IE8 Beta. The WebApps Working Group’s progress has been good; I expect this feature to be released in Firefox 3.next. Our long term goals ought to be to clean up the existing legacy of “ad-hoc” cross-domain access mechanisms on the web, and introduce safer primitives to give developers the capability of doing safe mashups.

• The Canvas3D initiative brings 3D graphics to the web, exposing an OpenGL 3D context to JavaScript via the canvas element. Pretty cool, eh? This allows 3D modeling on the web, with the potential of a low-level API that does the OpenGL stuff, possibly allowing for use of a shading language and even modeling formats like Collada. There’s also the possibility of a higher level layer of abstraction for 3D graphics in general. We’re raring to talk to the appropriate standards group, as well as get feedback on early implementations (check out Vlad’s extension).

• Worker Threads in JavaScript allow for abstraction around multiple threads exposed to web content, and allows for inter-thread communication using an API like postMessage. Use cases envision dedicated “background” processes happening asynchronously (and communicating with other processes on the spawning page). Proposals abound; Google Gears, WHATWG, and Mozilla’s DOM Worker Threads all have skin in the game, and we’re all working to arrive at a single straw person which will evolve either in the WHATWG or in the W3C WebApps WG, where it was proposed.

• Introducing SVG capabilities in CSS goes some of the way towards addressing the concern that the web stack consists of separate technologies that don’t “live together” well. Mozilla’s Robert O’Callahan blogged first about extending SVG’s notions of filter, mask and clip-path, and then about extending SVG paint servers. The resultant demos are …. just pretty darn awesome. In an ideal world, these would be extensions to the CSS charter, since these make the capabilities of SVG exposed to CSS.

• The birth of the Geolocation API for JavaScript was originally fraught with some small dissonance about where in the W3C the activity would live. In the WebApps Working Group, or in a newly minted Geolocation Working Group? It looks a lot like for reasons of corporate machinery (as well as, honestly, modular specification management), the Geolocation work will take place in a separate working group, despite objections from Mozilla, Opera, Apple, and Google (we’ll all still likely participate). Andrei Popescu from Google is a promising editor of the nascent specification, which reconciled ideas from Google’s Gears team as well as Mozilla’s Geolocation proposal.

• ECMAScript 3.1 and ECMAScript 4 are both enhancements to the defacto programming language of the web (and will manifest themselves in JavaScript and ActionScript — some things aren’t totally proprietary anymore, and both “proprietary” and “open” are words that ought to be used in an informed way). ECMAScript 3.1 proposes to recognize some “reality on the web” as well as introduces notions around safe subsets. ECMAScript 4 introduces “evolutionary” enhancements to ECMAScript — think classes and structural types in JavaScript

Anyone that thinks the web is standing still while proprietary models out-maneuver us ought to be disabused of that notion.