Standards for Web Applications on Mobile: February 2011 current state and roadmap

Latest version: http://www.w3.org/Mobile/mobile-web-app-state/
This version: http://www.w3.org/2011/02/mobile-web-app-state
Previous version: N/A

Web technologies have become powerful enough that they are used to build full-featured applications; this has been true for many years in the desktop and laptop computer realm, but is increasingly so on mobile devices as well.

This document summarizes the various technologies developed in W3C that increases the power of Web applications, and how they apply more specifically to the mobile context, as of February 2011.

This document is the first version of this overview of mobile Web applications technologies, and represents a best-effort of his author; the data in this report have not received wide-review and should be used with caution. Feedback on every aspect of this document should be sent to the author (dom@w3.org) and will serve as input for the next iteration of the document.

The features that these technologies add to the Web platform are organized under the following categories:

Graphics
Multimedia
Forms
User interactions
Data storage
Sensors and hardware integration
Network
Communication
Packaging
Performance & Optimization

The Web as an application development platform

In each category, a table summarizes for each feature:

which W3C specification defines the feature,
which W3C group is responsible of the said specification,
the level of maturity of the specification in the W3C Recommendation track (see below),
the estimated stability of the document, i.e. how widely the document is expected to change, as estimated by the author of this report, with three levels: low (the document is mostly stable), medium (some parts are stable, others are expected to change significantly), high (the document is expected to evolve significantly),
some rough qualitative indication on availability of implementations on mobile devices — a more thorough analysis will be include in a new version of this document,
a link to the latest editors draft of the document,
a link to the test suite for the said feature.

As a reminder, W3C creates Web standards by progressing documents through its Recommendation track, with the following stages:

Editors drafts represent the current view of the editors of the specification but have no standing in terms of standardization.
Working Drafts are early milestones of the Working Group progress.
Last Call Working Drafts signal that the Working Group has determined that the specification fulfills its requirements and all the known issues have been resolved, and thus requests feedback from the larger community.
Candidate Recommendations trigger a call for implementations where implementors are invited to implement the specification and send feedback; Working Groups are expected to show the specification gets implemented by running test suites they have developed.
Proposed Recommendations manifests that the group has gathered sufficient implementation experience, and triggers the final review by W3C Members
W3C Recommendations are stable and completed Web standards; these documents only get updated rarely, through the Edited Recommendation process, as a results from errata collected by Working Groups.

Prior to starting this standardization, a Working Group needs to be chartered, based on input from W3C Members, often through the organization of a workshop, after the reception of a W3C Member Submission, or as a follow-up to the work of a W3C Incubator Group.

Graphics

SVG, Scalable Vector Graphics, provides an XML-based markup language to describe two-dimensions vectorial graphics. Since these graphics are described as a set of geometric shapes, they can be zoomed at the user request, which makes them well-suited to create graphics on mobile devices where screen space is limited. They can also be easily animated, enabling the creation of very advanced and slick user interfaces.

The integration of SVG in HTML5 opens up new possibilities, for instance applying advanced graphic filters (through SVG filters) to multimedia content, including videos.

In complement to the declarative approach provided by SVG, the <canvas> element added in HTML5 enables a 2D programmatic API that is well-suited for processing graphics in a less memory intensive way. That API not only allows to render graphics, but can also serve as a way to make image processing and analysis.

Both SVG and HTML can be styled using CSS (Cascading Style Sheets); in particular, CSS3 (the third level of the specification) is built as a collection of specifications set to offer a large number of new features that make it simple to create graphical effects, such as rounded corners, complex background images, shadow effects (CSS Backgrounds and Borders), rotated content (CSS 2D Transforms), animations (CSS Animations, CSS Transitions), and even 3D effects (CSS 3D Transforms).

The cascading model of CSS is completed with the possibility of customizing the applied rules to the characteristics of the device through CSS Media Queries, a mechanism particularly useful on mobile devices to cater for the variation among screen sizes.

Fonts play also an important role in building appealing graphical interfaces, but mobile devices are in general distributed with only a limited set of fonts. WOFF (Web Open Font Format) addresses that limitation by making it easy to use fonts that are automatically downloaded through style sheets, while keeping the size of the downloaded fonts limited to what is actually needed to render the interface.

NB: work on defining a 3D graphic API called WebGL has started outside of W3C, as part of the Khronos Group; this API has been built to be compatible with OpenGL ES, i.e. for embedded systems, and is intended to work on mobile devices.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
2D Vector Graphics	SVG Tiny 1.2	SVG Working Group	Standard	Finished	New version of SVG (SVG 2.0) in preparation	Widely deployed (iOS, BlackBerry, WebKit on Nokia, webOS, Opera, Firefox, announced for Android, announced for Windows Phone)	High coverage
2D Programmatic API	HTML Canvas 2D Context	HTML Working Group	Working Draft	Mostly stable	Updated regularly	Widely deployed (iOS, BlackBerry, Android, webOS, Opera, Firefox, announced for Windows Phone)	Good coverage
Rounded Corners	CSS Backgrounds and Borders	CSS Working Group	Candidate Recommendation	Mostly finished	Updated regularly	Deployed as an extension in many mobile browsers	None
Complex background images						Limited (?)
Box shadow effects						Limited (?)
CSS 2D Transforms	CSS 2D Transforms Module Level 3		Working Draft	Stabilizing	Last update May 2010	Limited (?)	None
Animations	CSS Animations Module Level 3		Working Draft	First draft	Updated regularly	Limited (?)	None
Animations	CSS Transitions Module Level 3		Working Draft	Early draft	Last update Aug 2010	Limited (?)	None
3D Effects	CSS 3D Transforms Module Level 3		Working Draft	First draft	Last update Dec 2010	Very limited	None
CSS-based Adaptation	Media Queries		Candidate Recommendation	Mostly finished	Last update Aug 2010	Widely deployed	Good coverage
Downloadable fonts	WOFF File Format 1.0	WebFonts Working Group	Last Call	Stabilizing	Last update Nov 2010	Growing deployment	Good coverage

Multimedia

HTML5 adds two tags that improves dramatically the integration of multimedia content on the Web: the <video> and <audio> tags. These tags allows to embed respectively video and audio content, and make it possible for Web developers to interact much more freely with that content than they would through plug-ins. They make multimedia content first-class citizens of the Web, the same way images have been for the past 15 years.

While these tags allow to play multimedia content, the HTML Media Capture and the Media Capture API define mechanisms to capture and record multimedia content using attached camera and microphones, a very common feature on mobile devices.

Beyond recording, two additional APIs add multimedia manipulation capabilities to the Web platform. We have already mentioned the Canvas 2D Context API: it enables modifying images, which in turn opens up the possibility of video editing. In a similar vein, a W3C Incubator Group has been working on an Audio API (Mozilla’s proposal draft) that makes it possible to modify audio content, as well as analyze and synthesize sounds — this work is now under consideration to be moved under proper standardization.

The combination of all these features mark the starting point of the Web as a comprehensive platform for multimedia, both for consuming and producing. The rising interest around bridging the Web and TV worlds (manifested through the W3C Web and TV Interest Group) should strengthen that trend in the coming months.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
Video playing	HTML5 `video` element	HTML Working Group	Working Draft	Stabilizing	Updated regularly	Growing deployment	Just started
Audio playing	HTML5 `audio` element	HTML Working Group	Working Draft	Stabilizing	Updated regularly	Growing deployment	Barely started
Capturing audio/video	HTML Media Capture	Device APIs & Policy Working Group	Working Draft	Early draft	Last update Nov 2010	Very limited	None
Capturing audio/video	The Media Capture API	Device APIs & Policy Working Group	Working Draft	Early Draft	Last update Dec 2010	None (?)	None
Image & Video analysis, modification	HTML Canvas 2D Context	HTML Working Group	Working Draft	Mostly stable	Updated regularly	Widely deployed (iOS, BlackBerry, Android, webOS, Opera, Firefox, announced for Windows Phone)	Good coverage
Audio analysis, modification	None	Audio Working Group (not started yet)	N/A	Not started	Mozilla Audio API	None	None

Forms

The ability to build rich forms with HTML is the basis for user input in most Web-based applications. Due to their limited keyboards, text input on mobile devices remains a difficult task for most users; HTML5 address parts of this problem with offering new type of form controls that optimizes the way users will enter data:

date and time entries can take advantage of a number of dedicated form controls (e.g. <input type="date">) where the user can use a native calendar control;
the <input type="email">, <input type="tel"> and <input type="url"> can be used to optimize the ways user enter these often-difficult to type data, e.g. through dedicated virtual keyboards, or by accessing on-device records for these data (from the addressbook, bookmarks, etc.);
the pattern attribute allows both to guide user input as well as to avoid server-side validation (which requires a network round-trip) or JavaScript-based validation (which takes up more resources);
the placeholder attribute allows to guide user input by inserting hints as to what type of content is expected in a text-entry control;
the new <datalist> element allows to create free-text input controls coming with pre-defined values the user can select from.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
Date and time entries	HTML5 Date and Time state of `input` element	HTML Working Group	Working Draft	Stabilizing	Updated regulalry	Limited	None
Customized text entries (`tel`, `email`, `url`)	HTML5 telephone, email and URL state of `input` element			Stabilizing	Updated regularly	Limited (?)	None
Input pattern	HTML5 `pattern` attribute			Stabilizing	Updated regularly	Very limited (?)	None
Input hint	HTML5 `placeholder` attribute			Stabilizing	Updated regularly	Limited (?)	None
Pre-defined values for text entries	HTML5 `datalist` element			Stabilizing	Updated regularly	Very limited (?)	None

User interactions

An increasing share of mobile devices rely on touch-based interactions. While the traditional interactions recognized in the Web platform (keyboard, mouse input) can still be applied in this context, a more specific handling of touch-based input is a critical aspect of creating well-adapted user experiences. As a result, work has started on defining Touch Events in the DOM (Document Object Model).

Conversely, many mobile devices use haptic feedback (such as vibration) to create new form of interactions (e.g. in games); work on a vibration API is under consideration in the Device APIs & Policy Working Group (see ongoing discussions.)

But as the Web reaches new devices, and as devices gain new user interactions mechanisms, it also becomes important to allow Web developers to react to a more abstract set of user interactions: instead of having to work in terms of “click”, “key press”, or “touch event”, being able to react to an “undo” command, or a “next page” command however the user communicated it to the device will prove beneficial to the development of Web applications. Work on abstract DOM events that would address this need is planned as part of the Web Events Working Group.

Mobile devices follow their users everywhere, and many mobile users rely on them to remind them or notify them: the Web Notifications specification proposes to add that feature to the Web environment.

Mobile devices, and mobile phones in particular, are also in many cases well-suited to be used through voice-interactions; the HTML Speech Incubator Group is exploring the opportunity of starting standardization work around a framework that would make it possible for users to interact with a Web page through spoken commands (see their use cases and requirements.)

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
Touch-based interactions	Touch Events Specification (no public draft yet)	Web Events Working Group	N/A	Editors draft only	Updated regularly	Growing deployment	None
Vibration	N/A	Device API & Policy	N/A	Not started	Not started	None	None
Intent-based events	N/A	Web Events Working Group	N/A	Not started	Not started	None	None
Notification	Web Notifications (no public draft yet)	Web Notifications Working Group	N/A	Editors draft only	Regularly updated	None	None
Speech-based interactions	N/A	HTML Speech Incubator Group	N/A	N/A	Use cases and requirements	N/A	N/A

Data storage

A critical component of many applications reside in the ability to save state, export content, as well as integrate data from other files and services on the system.

For simple data storage, the Web Storage specification offers two basic mechanisms, localStorage and sessionStorage, that can preserve data respectively indefinitely, or on a browser-session basis.

For richer interactions, the Web platform has a growing number of APIs to interact with a device filesystem: the File Reader API makes it possible to load the content of a file, the File Writer API allows to save or modify a file, while the nascent FileSystems API give access to more general file operations, including directory management.

On top of this file-based access, the Indexed Database API defines a database of values and hierarchical objects that integrates naturally with JavaScript, and can be queried and updated very efficiently. Note that the work around a client-side SQL-based database which had been started in 2009 has been abandoned in favor of this new system.

Applications can also benefit from integrating with existing data records; on mobile devices, the addressbook and calendar are particularly useful source of information, which the Contacts API and the Calendar API bring access to.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
Simple data storage	Web Storage	Web Applications Working Group	Working Draft	Stabilizing	Updated regularly	Well deployed	None
File reading	File API	Web Applications Working Group	Working Draft	Stabilizing	Last update Dec 2010	Limited (?)	None
File writing	File API: Writer	Web Applications Working Group	Working Draft	Early draft (but starting to stabilize)	Last update Oct 2010	Limited (?)	None
Filesystems operations	File API: Directories and System	Web Applications Working Group	Working Draft	Early draft	Last update Oct 2010	None	None
Database query/update	Indexed Database API	Web Applications Working Group	Working Draft	Still changing, but starting to stabilize	Last update Dec 2010	Very limited (?)	None
Addressbook data	Contacts API	Device APIs & Policy Working Group	Working Draft	Still changing, but starting to stabilize	Regularly updated	Very limited	None
Calendar data	Calendar API (no public draft yet)	Device APIs & Policy Working Group	N/A	Editors draft only	Regularly updated	Very limited	None

Sensors and hardware integration

Mobile devices are packed with sensors, making them a great bridge between the real and virtual worlds: GPS, accelerometer, ambient light detector, microphone, camera, thermometer, etc.

To take full advantage of these sensors in mobile Web applications, Web developers need to be provided with hooks to interact with them.

The Geolocation API provides a common interface for locating the device, independently of the underlying technology (GPS, WIFI networks identification, triangulation in cellular networks, etc.)

Work has also started on providing access to orientation and acceleration data via the DeviceOrientation Event Specification.

The System Information API proposes a generic API to get and monitor data from sensors, although the Working Group producing it is evaluating whether that generic approach is the most practical way forward.

As already mentioned in the section on multimedia, the Media Capture API opens up access to camera and microphone.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
Geolocation	Geolocation API	Geolocation Working Group	Candidate Recommendation	Mostly finished	Regularly updated	Widely deployed	Good coverage
Accelerometer / Orientation	DeviceOrientation Event Specification (no public draft yet)	Geolocation Working Group	N/A	Editors draft only	Regularly updated	Limited	None
Generic sensors	The System Information API	Device APIs & Policy Working Group	Working Draft	Not clear the group will continue in the current direction	Last update Jan 2011	None	None
Camera & Microphone capture	The Media Capture API	Device APIs & Policy Working Group	Working Draft	Early Draft	Last update Dec 2010	None (?)	None

Network

Network connectivity represents a major asset for mobile devices: the Web is an immense store of content, as well as an almost endless source of processing power, overcoming two of the limitations of mobile devices.

The Web platform is growing a number of APIs that facilitate establishing network connectivity in different contexts.

XMLHttpRequest (the “X” in AJAX) is a widely deployed API to load content from Web servers using the HTTP and HTTPs protocol.

A second version of that specification, XMLHttpRequest Level 2 completes the existing API with the ability to make requests on servers in a different domain, programmatic feedback on the progress of the network operations, and more efficient handling of binary content.

By default, browsers prevent from making request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port); this rule protects the user from having a Web site abusing from the user credentials and data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing mechanism, opening up much wider cooperation across Web applications and services.

XMLHttpRequest is useful for client-initiated network requests, but mobile devices with their limited network capabilities and the cost that network requests induce on their battery (and sometimes on their users bill) can often make better use of server-initiated requests. The Server-Sent Events API allows to trigger DOM events based on push notifications (via HTTP and other protocols.)

The WebSocket API, built on top of the IETF WebSocket protocol, offers a bidirectional, more flexible, and less resource intensive network connectivity.

Of course, an important part of using network connectivity relies on being able to determine if such connectivity exists, and the type of network available. The HTML5 onLine DOM flag (and its associated change event, ononline) signals when network connectivity is available to the Web environment.

Part of the System Information API addresses discovery of the network characteristics (e.g. WIFI vs 3G, or available bandwidth), but this proposal is likely to be recast into a more simple network-centric API (see related discussion.)

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
HTTP(s) network API	XMLHttpRequest	Web Applications Working Group	Candidate Recommendation	Mostly finished	Regularly updated	Widely deployed	Good coverage
XHR2	XMLHttpRequest Level 2	Web Applications Working Group	Working Draft	Still changing, but starting to stabilize	Updated regularly	Very limited (?)	None (?)
Cross-domain requests	Cross-Origin Resource Sharing	Web Applications Working Group	Working Draft	Close to stabilizing	Last update November 2010	Getting deployed (?)	None (?)
Server-pushed requests	Server-Sent Events	Web Applications Working Group	Working Draft	Still changing but stabilizing	Regularly updated	Limited (?)	None (?)
Bidirectional connections	The WebSocket API	Web Applications Working Group	Working Draft	Still changing but stabilizing	Regularly updated	None (?)	None
on-line state	HTML5 onLine DOM state	HTML Working Group	Working Draft	Mostly stable	regularly updated	Getting deployed	None
Network characteristics	Network Property in The System Information API	Device APIs & Policy Working Group	Working Draft	The group will likely NOT continue in the current direction for the network aspects	Last update Jan 2011	None	None

Communication

Mobile devices are often communications devices; beyond connection to on-line services, allowing communications between users, but also between devices and between applications is an important aspect of a good mobile development platform.

The Messaging API completes the existing ability to create and send message through links (with sms:, mms: and mailto: URI schemes) with more control on adding attachments and the success of the message sending.

The postMessage API of HTML5 Web Messaging allows for Web Applications to communicate between each other.

Exploratory work in the Device APIs & Policy Working Group, inspired by the Web Introducer and similar works, would also open up possibilities of closer integration of Web applications.

The proposed creation of a Web Real-Time Communications Working Group (see announcement) should enable a much wider set of communication opportunity:

Peer-to-peer connection across devices,
P2P Audio and video streams allowing for real-time communications across users.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
Emails, SMS and MMS with generated attachments	The Messaging API	Device APIs & Policy Working Group	Working Draft	Still subject to large changes	Last update Jan 2011	None	None
Inter-app communications	HTML5 Web Messaging	Web Applications Working Group	Working Draft	Still changing but stabilizing	Regularly updated	Limited (?)	None
Inter-app triggers	None	Possibly Device APIs & Policy Working Group	N/A	Not started	Possible inspiration from Web Introducer	None	None
P2P connections	None	Proposed Web Real-Time Communications Working Group	N/A	None	N/A	None	None
P2P Video/Audio streams	None	Proposed Web Real-Time Communications Working Group	N/A	None	N/A	None	None

Packaging

An important aspect of the user experience of applications is linked to how the user perceives the said application is available permanently (even when off-line, which is particularly important on mobile devices), as well as how it can shared and distributed — this is addressed by packaging the application adequately.

The Web platform offers two complementary approaches to packaging Web applications:

HTML5’s ApplicationCache enables access to Web applications off-line through the definition of a manifest of files that the browser is expected to keep in its cache;
the W3C Widgets family of specifications define a framework for distributing Web applications as Zip files completed by a configuration file (see Widget Packaging and Configuration); this configuration file is the basis for additional features such as signature of applications , controlled access to advanced APIs, restricted network usage, etc.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
Application Cache	HTML5 Application Cache	HTML Working Group	Working Draft	Still changing but stabilizing	Regularly updated	Getting deployed	None
Widgets	Widgets Packaging & Configuration	Web Applications Working Group	Last Call	Mostly finished	Regularly updated	Getting deployed	Good coverage
	Digital Signatures for Widgets		Candidate Recommendation	Mostly finished	Regularly updated	Getting deployed	Good coverage
	Widget Access Request Policy		Candidate Recommendation	Mostly finished	Last update Apr 2010	Limited	None (?)

Performance & Optimization

Due to their limited CPU, and more importantly to their limited battery, mobile devices require a lot of attention in terms of performance.

The work started by the Web Performance Working Group on Navigation Timing gives tools to Web developers for optimizing their Web applications.

Beyond optimization of resources, the perceived reactivity of an application is also a critical aspect of the mobile user experience; as such, the thread-like mechanism made possible via Web Workers allows to keep the user interface responsive by offloading the most resource-intensive operations into a background process.

The Mobile Web Application Best Practices provide general advices on how to build Web applications that work well on mobile devices, taking into account in particular the needs for optimization.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Test suite
Timing hooks	Navigation Timing	Web Performance Working Group	Last Call	Stabilizing	Regularly updated	None (?)	None
Threading	Web Workers	Web Applications Working Group	Working Draft	Stabilizing	Regularly updated	Limited (?)	None
Optimization Best Practices	Mobile Web Application Best Practices	Mobile Web Best Practices Working Group (now closed)	Standard	Finished	N/A	N/A	N/A