Building the Web, One Spec at a Time

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.

8 thoughts on “Building the Web, One Spec at a Time”

  1. SL & Flash excel at animation. I’m amazed by the commentators who forget about this in their rush to endorse the current browsers.

    I know there are AJAX libraries to do animation, but it’s a poor substitute for the impressive capabilities in SL & Flash.

    Second, HTML form fields are not composable.

    Third, the web layout manager (ie CSS box model) is very restrictive. It’s great for web documents, but poor for web applications. You only understand this when you try to port a moderately complex SL/Flash application to the web.

    I don’t see any of this stuff being addressed and deployed in browsers before 2010 – that’s why many developers are *forced* into using SL/Flash.

  2. Dont’ forget WAI-ARIA, which Mozilla is leading the way in!

    This finally allows accessibility to break out of the box it was in. Which means, organizations that must make accessible content can break out of the box as well. It brings AJAX, JavasScript widgets, etc. all into the toolbox of organizations with accessibility requirements (which fortunately includes some significant ones). It works today in Firefox, and all 4 major browser vendors are now implementing it.

    A11y and innovation don’t need to be at odds with each other.

  3. RichB: I totally agree with your point about animation, but… check out processing.js and tell me that we haven’t come a long way :-) Yes, as far as tools go, we have a lot of work to do. Also, can you shed a bit more light on what you mean by “form fields are not composable?” Do you mean currently, or even in the context of the WebForms work that we want to take into HTML5?

    Aaron: yes, of course, my bad. I should have mentioned WAI-ARIA, and of course, I totally agree with your comment that A11y and innovation don’t need to be at odd with each other.

  4. Hi Arun,
    My question is a bit out of context of this post. I was going through your examples of CORS @(http://arunranga.com/examples/access-control/) , but didnt find any examples related to cross-protocol ajax calls. Is it even possible to make cross-protocol calls(for eg. https to http or vice versa ) ? I tried simulating the same, but without any success. I was just wondering if you had any hints/idea on it ? Sorry for posting in wrong section, but I didnt find any better relevant section where I could post a comment.

  5. I’m very sorry for the delay in response, but you can’t do cross-protocol calls using CORS. You can cross domains, but not protocols :) This isn’t allowed for security reasons.

Leave a Reply

Your email address will not be published. Required fields are marked *