Mozilla Standards Blog

This post is by David Baron, who is a developer at Mozilla and is Mozilla’s representative to the W3C Advisory Committee.

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”.

This post is by David Baron, who is a developer at Mozilla and is Mozilla’s representative to the W3C Advisory Committee.

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.)

Last year, some prominent web developers weighed in on an increasingly spirited discussion about the App Store model versus The Web. Discussion about how to build really compelling mobile web applications that work on multiple mobile web browsers continues. But questions of market economics aside, some important technical questions crop up: is the web as an application platform capable of all the things we expect from a good platform? How do web pages integrate with the devices that they run on, and how can even more APIs be coined? And of course, the perennial: can the web platform (and web applications) replace the use of native code?

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.

Read the rest of this entry »

(cross-posted from hacks.mozilla.org)

Even without a draft specification of WebGL in circulation, we’ve seen some promising 3D content using WebGL appear on the web, put together mainly through developer ingenuity and the fact that Firefox, Chromium, and WebKit are open source projects with early support for the technology. Today, the WebGL Working Group at Khronos released a provisional public draft of the WebGL specification, and we are very excited for what this means for the web.

For one thing, it means more developers can get involved in the evolution of WebGL. There’s a public mailing list set up, so that you can engage directly with members of the WebGL Working Group, as well as a web forum. It’s important to note that the specification is not yet finalized. Participation from the web community is essential towards finalizing the specification, which we hope to do in the first quarter of 2010.

It also means that there are implementations of the draft specification that you can begin to test. You can obtain a Firefox nightly that implements the WebGL draft specification, and can turn on WebGL support in that build by following these steps:

• Type “about:config” in your browser’s URL bar
• Do a search for “webgl” in the Filter field
• Double-click the “enabled_for_all_sites” preference to change it to “true”

Other browsers that support the draft WebGL specification are listed on the WebGL Wiki.

Now of course, this is hardware-accelerated 3D graphics in an early beta, and for now requires an OpenGL 2.0-capable GPU and drivers. In particular, most flavors of Intel’s integrated GPUs will not work straight out of the box (such as the GMA900/GMA950 often found in laptops). Developers who build nightly builds of the browser can induce software rendering using Mesa, and should check out Vlad’s blog post for doing this on Windows. Caveat emptor: building software rendering using Mesa into a Firefox nightly is likely to yield slower performance, and is only for the intrepid.

WebGL is a royalty-free, cross-platform API that brings OpenGL ES 2.0 to the web as a 3D drawing context within HTML5′s Canvas element, exposed as low-level interfaces within the Document Object Model.

Developers familiar with the Canvas 2D context will recognize that WebGL as another context for Canvas:

// get the canvas element in the DOM
var canvas = document.getElementById("canvas3D");
var gl = canvas.getContext("experimental-webgl");

Note that till the specification is finalized, the context is called experimental-webgl.

WebGL uses the OpenGL shading language, GLSL ES, and can be cleanly combined with other web content that is layered on top or underneath the 3D content. It is an emerging web standard, and is designed to be used with other parts of the web platform. The release of the draft specification is one step in bringing about a plugin free 3D API to the web, usable straight out of the box. People have already begun using it to create compelling libraries. Check out X3DOM, which is a JavaScript library using WebGL that allows users to author content in X3D. We expect developer ingenuity to surprise and awe us, as it always has.

References

• Review the WebGL draft specification
• Get involved! WebGL Homepage on Khronos
• Read articles and contribute on the WebGL Wiki
• A blog about learning WebGL
• Find 3D recipes in the learning WebGL Cookbook

Cross-posted from hacks.mozilla.org

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.

Yesterday at the Game Developers Conference in San Francisco, Mozilla and the Khronos Group (the folks behind the OpenGL family of standards) announced a new initiative to bring accelerated 3D graphics to the web. This is a promising new direction for web applications, and adds to the rich mix of activities in forum such as the W3C and WHATWG to evolve the web platform.

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.

Read the rest of this entry »

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?

Read the rest of this entry »

At the Mozilla Summit, I held a session on Standards. The organizational powers that be gave me the Big Room, and before long I stood in relative darkness on stage discussing standards with the mavens within our community that pay attention to such things.

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.

Read the rest of this entry »

Standards meetings rarely generate the kind of buzz that the ECMAScript meeting Brendan and I attended in Oslo did; check out John Resig’s blog post, and then Doug Crockford’s. And, there’s also the Open Web Podcast on ECMAScript Harmonization that John Resig, Alex Russell, and Dion Almaer hosted Brendan and I on. Turns out that time spent indoors with computer language design mavens in sunny Oslo in late July have sowed the seeds of harmony. But first, some back story.

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.

Read the rest of this entry »

(Cross-posted from arunranga.com)

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

Read the rest of this entry »