Mozilla Standards Blog

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.

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.