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.

JavaScript performance in all major browsers has shown marked improvements over time, paving the way for it to be used for more sophisticated classes of applications. Many graphics applications, including popular games, leverage hardware acceleration, and subsets of OpenGL (such as OpenGL ES1.1) are already available on smartphones. The initial activity proposal is to consider a simple binding of OpenGL ES2.0 to JavaScript, and exposing that to an HTML5 Canvas context. This is how a 2D drawing context is exposed to the web for use with a JavaScript API; the proposed mechanism is to do this for a 3D context as well. As exciting as this is for the web and for us at Mozilla, it’s worth explaining our choices, and raising some questions.

We chose Khronos to start with, since that’s the home of OpenGL, and the proposal is to start with an OpenGL subset such as OpenGL ES2.0. This is a very low-level API with a lot of C language structures, and perhaps an early task for the working group would be to figure out how to expose that to JavaScript. This isn’t a fait accompli, and we look forward to help and collaboration from other major players. Naturally, security is a paramount consideration. Google announced support for the activity, and we look forward to others doing so soon as well.

Would web developers actually use something this low level? While we anticipate the influx of a new type of web developer (who may also be a games developer, or interested in 3D visualization), it’s worth pointing out that a standardization principle that’s served the web well is to expose pretty low level primitives in browsers, and allow third party JavaScript libraries to take on the task of syntactic sugar and higher level abstractions. Applications toolkits such as dojo, jQuery, and Prototype simplify developers lives; the same can occur in the 3D arena.

It’s also worth pointing out that this endeavor with Khronos to bring a subset of OpenGL to the web is just the first step. Higher level APIs with retained mode graphics are likely to follow suit. The discussion officially started yesterday, so we’re glowing with fresh possibility in uncharted terrain here.

Also read Vlad’s thoughts on all this — he wrote the extension that was the initial experimental implementation, and made this happen. And Chris Blizzard’s thoughts.

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.

Just So Stories about why exactly JavaScript became the de facto programming language of the web abound; that it is very popular is either a blessing or a curse for its creator, who says he still sees it as the “quickie love child between C and Self.” Its programming language antecedents, at least in terms of inspiration and influence, have resulted in a language with Java-like syntax, Scheme-like first class functions, and Self-like prototypes. It is implemented, with differences, in every browser, and is here to stay. But how should it evolve? As an integral part of the web platform, what should it be capable of in the future? And, what guiding principles should inform these weighty decisions? Glad you asked. This is a blog post about harmony in the ECMAScript process; or, about how opinionated technologists forgo stalemates and arrive at some measure of reconciliation.

ECMAScript as a standard informs implementations such as JavaScript (in Firefox, Safari, and Opera, to name a few), JScript (in Microsoft’s Internet Explorer) and ActionScript (in Flash). The current version is ECMAScript 3 (formally called ECMA-262 revision 3 [Link to HTML Version]). Note, however, that whatever is sanctioned by the specification remains frozen in time, and I don’t just mean the discovery of errata as time goes on. The language grows; amongst other things, new APIs and programming constructs get introduced. More importantly, developers, particularly those that give other developers useful, reusable stuff like prototype, dojo, or JQuery, want the language to evolve, whether that includes syntactic conveniences or features.

Evolutionary steps are often tentative and experimental, till market popularity dubs them otherwise. JavaScript 1.6 in Mozilla (implemented in Firefox 1.5) introduced Array extras as syntactic sugar, on top of what ECMAScript 3 says you can do with Arrays:


//location or index methods
indexOf
lastIndexOf


//iterative methods
every()
filter()
forEach()
map()
some()


It also included support for E4X, which itself was standardized via an ECMA activity (see ECMA-357: ECMAScript for XML).

Then, JavaScript 1.7 (which is in Firefox 2.0) introduced generators (the yield keyword, for example, typically used in conjunction with while loops) and iterators (the Iterator object and next()), Array comprehensions (ways to initialize arrays using generators and iterators), elegant destructuring assignments ([a,b] = [b,a]), and let as the new “scope restricted” var.

Most recently, JavaScript 1.8 (which is in Firefox 3.0) gives us lambda-like function declarations (function(x) x*x // look Ma, no curly braces or return! ), more syntactic sugar around generator expressions, and a few more Array extras (reduce and reduceRight).

It made sense to have a revision to ECMAScript 3, perhaps to acknowledge reality, and to standardize the moving parts that were already coming into vogue via JavaScript 1.6 and 1.7 (including catering to the clamoring for getters and setters). Getters, setters, and the Array extras (extremely useful for DOM manipulation, among other things) in particular became hot ticket items.

In parallel, visions for the longer term future of ECMAScript were also being distilled, under the name ECMAScript 4. Adobe’s ActionScript 3.0, for example, introduced packages, namespaces, classes and interfaces, along with type annotations as potential optimizations (check out syntax like var x:int=80), based on early ideas that accumulated within the ECMAScript 4 framework.

Thus, two standardization endeavors under the aegis of the ECMA TC39 group: ECMAScript 3.1 and ECMAScript 4, respectively. ECMAScript 3.1 (ES3.1) would be a revision of ECMAScript 3, which had been untouched for a long time. And ECMAScript 4 (ES4) would look at the more evolutionary aspects of the language, introducing newer syntax, constructs, and capabilities. They would exchange ideas on two different mailing lists. Of course, it made sense that ES3.1 would be a subset of ES4. There would be a modest update (ES3.1) and a longer term endeavor (ES4), which sums up some of the back story (at least in terms of aspirations).

But of course, it wasn’t that simple (is it ever?). The ES3.1 group was informed by design goals including simplicity and security (which are definitely laudable and good goals for the Web, any resultant discord notwithstanding); in particular, notions of object capability played a role in language design, given its constituents, who include the folks behind E and SmallTalk. It became clear that the agenda for ES3.1 wasn’t merely {ES3 + “The Recognition of Reality (Defacto Standards)”}. A few saw it as a chance to clean up problems in a misunderstood language. There was the introduction of a secure subset mode to better enable safer mashups, and library additions such as Object.freeze() which enforced the readonly-ness of object properties. Various notions of types were also deemed slippery slopes that ought to be traversed with caution, lest the dynamic nature of ECMAScript languages be irreversibly compromised. In general, newer syntax in ES4 was viewed as a sort of troubling adventurism by the ES3.1 group, while similar misconceptions about ES3.1’s conservative approach to ECMAScript were harbored by the ES4 group. Doug Crockford (of JSON fame) along with Microsoft put forth a proposal to refocus efforts, suggesting that ES4 was too much of a radical departure, making it a totally different language.

Much can be made about disharmony in the ECMAScript process — about security considerations and design philosophies pitted against each other, thwarting the advent of newer capabilities to the language. Discord, however, is NOT the big story. At the meeting in Oslo that took place in July, the ECMAScript group arrived at the notion of ECMAScript Harmonized, a reconciliation between the two groups. Some design compromises needed to be arrived at, but they are good for the Web. To quote Brendan’s executive summary:

Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.

Namespace usage implies a module system of some sort (and namespaces and packages go hand in hand, here), but in the case of the Global Object, the module inclusion system is our tried and tested (albeit problematic) <script src=>. Then there’s also:

Plus, as some JS implementors have noted with concern, multiple open namespaces impose runtime cost unless an implementation works significantly harder.

So let’s agree to forgo namespaces in the global object. John Resig asked me on the podcast if namespaces and packages was one concession too many to make, made under pressure from the ES3.1 group (who see the present namespace proposal as anathema to their design principles). Actually, it was the ES4 group that proposed forgoing packages and namespaces, voluntarily, as better for the reality of scripts on the Web today. I suppose these can exist as particular extensions within ActionScript to whatever the newly harmonized language looks like.

But, classes as syntactic sugar are still in, and that’s a really exciting instrument of abstraction (and syntactic sugar). I talk on the podcast about how we spent a lot of time in Oslo engaging in desugaring exercises as useful for harmony, proving that classes can be desugared to ES3.1 syntax, with Object.freeze.

As Brendan’s email shows, our work is still cut out for us. Some discussion around nominal vs. structural typing needs to occur, as well as harmonization around generators and iterators. And then there’s the issue of inheritance, which still needs to be worked out, while preserving the prototype-based inheritance that exists today. Zero, single, or multiple? What do developers really want? Let’s start easy, and then think about it.

Concern about security by those that pave the Web is, of course, good for the Web. But so is evolution. A hung committee full of implementers serves neither goal. Now that we’re all harmonized, let’s get back to rough consensus and running code, and let’s get on with it. I’m looking forward to it.

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.