Standards for Web Applications on Mobile: current state and roadmap

June 2013

Latest version

http://www.w3.org/Mobile/mobile-web-app-state/

This version

http://www.w3.org/2013/06/mobile-web-app-state/ (PDF version)

Previous version

http://www.w3.org/2013/02/mobile-web-app-state/

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 increase the capabilities of Web applications, and how they apply more specifically to the mobile context. A good subset of these technologies are described and explained in the W3C on-line training on programming Web applications.

1. Graphics
2. Multimedia
3. Device Adaptation
4. Forms
5. User interactions
6. Data storage
7. Personal Information Management
8. Sensors and hardware integration
9. Network
10. Communication_and_Discovery
11. Packaging
12. Performance & Optimization

Status and changes

This document is the tenth edition of this overview of mobile Web applications technologies. The previous edition was released in February 2013. A live version of this document accepts contributions in the W3C Wiki.

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.

This edition adds a printer-friendly PDF version of the document, and, where appropriate, links to the Github repository of W3C test suites.

It documents the following changes in the Web platform since February 2013:

• HTML 5.1 incorporates additions to HTML5 that helps Web apps on mobile, in particular the ability to run image processing in separate thread (via Canvas proxy), and improved form completion features;
• Web Animations, Encrypted Media Extensions, Contacts Manager API, Messaging API, Runtime and Security Model for Web Applications were published as a First Public Working Draft;
• HTML Media Capture, Pointer Events, Resource Timing have reached the Candidate Recommendation status;
• the Vibration API went back to Last Call (from Candidate Recommendation) to cater for some changes based on implementation feedback;
• Touch Events, Web Storage are now a Proposed Recommendation;
• Progress on Web Intents and associated specifications has stalled due to unresolved concerns on its integration in user interactions;
• A Patent Advisory Group is being convened on the Push API following a patent disclosure and exclusion;
• the document now tracks Media Source Extensions that provides an API to generate media content via JavaScript;
• this document now tracks NavigationController, the likely replacement for ApplicationCache to manage off-line Web apps;
• Level 4 of Media Queries, available as an Editors Draft, proposes the addition of CSS Media Queries to detect the type of pointing device, or the ambient luminosity;
• An editors draft of the NFC API was made available.

Document structure

The features that these technologies add to the Web platform are organized under the following categories: graphics, multimedia, device adaptation, forms, user interactions, data storage, personal information management, sensors and hardware integration, network, communication and discovery, 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 stage 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 qualitative indication on availability of implementations on mobile devices, based on data collected primarily from Can I Use… and mobile HTML5, completed with data from Mozilla developer network, QuirksMode, as well as the author’s understanding of the mobile devices market (see also the code used to generate the support icons)
• a link to the latest editors draft of the document,
• When available, a link to a relevant tutorial on WebPlatform Docs, and to relevant on-line training courses on W3DevCampus
• 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 implementers 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 standardization, a Working Group needs to be chartered, based on input from W3C Members, often through the organization of a workshop, or after the reception of a W3C Member Submission.

W3C has set up Community Groups, a mechanism that allows anyone to do experimental work within the W3C infrastructure, under IPR rules that are compatible to transition the work to the W3C standardization process.

1. Graphics

SVG, Scalable Vector Graphics, provides an XML-based markup language to describe two-dimensions vector 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. SVG 2.0 is set to facilitate that integration and complete the set of features in SVG.

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 rendering graphics, but can also be used to do image processing and analysis — HTML 5.1 adds the ability to do that processing in a separate Web Worker.

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 Transforms, including with 3D effects), animations (CSS Animations, and CSS Transitions).

Animations, which can also be managed via scripting through the API exposed in Web Animations, can be resource intensive — the possibility offered by the Timing control for script-based animations API to manage the rate of updates to animations can help keep them under control.

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.

Another important aspect in graphics-intensive applications (e.g. games) is the possibility to use the entire screen to display the said graphics; the Fullscreen API lets a Web application requests and detects full screen display.

Likewise, in these scenarios, it is often useful to be able to lock the orientation of the screen; the Screen Orientation API allows not only to detect orientation change, but also to lock the orientation in a specific state.

NB: a 3D graphic API for HTML5 canvas, called WebGL, has been developed 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	Developers doc	Test suite
2D Vector Graphics	SVG 1.1	SVG Working Group	Recommendation	Finished	New version of SVG (SVG 2.0) in preparation	Widely deployed		High coverage
	SVG 2		Working Draft	Early draft	editors draft	N/A		N/A
2D Programmatic API	HTML Canvas 2D Context	HTML Working Group	Candidate Recommendation	Stable	Updated regularly	Widely deployed		Fork me on GitHub Good coverage
	HTML 5.1 Canvas Proxy		Working Draft	Early draft	Updated regularly	None		None
Complex layouts	CSS Flexible Box Layout Module	CSS Working Group	Candidate Recommendation	Mostly finished	Updated regularly	Growing deployment		Well started
Rounded Corners	CSS Backgrounds and Borders		Candidate Recommendation	Mostly finished	Updated regularly	Well deployed		Good coverage
Complex background images						Well deployed
Box shadow effects						Widely deployed
2D Effects	CSS Transforms		Working Draft	Mostly stable	Latest update Feb 2013	Well deployed		Good coverage
3D Effects				Stabilizing		Well deployed
Animations	CSS Animations Module Level 3		Working Draft	Early draft	Updated regularly	Well deployed		None
	CSS Transitions Module Level 3		Working Draft	Early draft	Latest update Feb 2013	Well deployed		None
	Web Animations	CSS Working Group and SVG Working Group	Working Draft	Early draft	Regularly updated	None		None
	Timing control for script-based animations API	Web Performance Working Group	Last Call Working Draft	Stabilizing	Regularly updated	Well deployed		Well started
Downloadable fonts	WOFF File Format 1.0	WebFonts Working Group	Recommendation	Finished	Latest update Dec 2012	Good deployment		Good coverage
Fullscreen display	Fullscreen API	Web Apps and CSS Working Groups	Working Draft	Early draft	Regularly updated	Limited		None
Orientation Lock	The Screen Orientation API	Web Apps Working Groups	Working Draft	Early draft	Regularly updated	Very limited		None

2. Multimedia

HTML5 adds two tags that dramatically improve the integration of multimedia content on the Web: the <video> and <audio> tags. Respectively, these tags allow embedding 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 20 years.

The playback content can be augmented and completed via Media Source Extensions that lets developers generate media content in JavaScript.

To cater for the needs of some content providers, a proposal to enable playback of protected content, Encrypted Media Extensions is an API that is under consideration in the HTML Working Group.

The Pick Media Intent offers a Web-intent based approach to search and retrieve locally or remotely stored media content, while the Networked Service Discovery API opens the door for integrating DLNA-hosted content into Web applications.

While the new HTML5 tags allow to play multimedia content, the HTML Media Capture defines a markup-based mechanism to access captured multimedia content using attached camera and microphones, a very common feature on mobile devices. The Web Real-Time Communications Working Group and the Device APIs Working Group are building together an API (getUserMedia) to directly manipulate streams from camera and microphones, as well as an API to record these streams into files.

Beyond capturing and 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, the Audio Working Group is working on an API that that makes it possible to modify audio content, as well as analyze, modify and synthesize sounds, the Web Audio API.

The combination of all these features marks 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. Mobile devices are expected to take a growing role in many users TV experience, providing a “second screen” experience, where users can find more information on or interact with a TV program they're watching via their mobile devices.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Video playback	HTML5 video element	HTML Working Group	Candidate Recommendation	Mostly stable	Updated regularly	Good deployment		Fork me on GitHub Well started
Audio playback	HTML5 audio element		Candidate Recommendation			Good deployment		Fork me on GitHub Started
Protected content playback	Encrypted Media Extensions		Working Draft	Early draft	Latest update May 2013	Very limited		None
Multimedia Gallery access	Pick Media Intent	Device APIs Working Group	Working Draft	Early Web-intents based approach; stalled due to lack of progress on Web Intents	Last updated Aug 2012	None		N/A
	Networked Service Discovery		Working Draft	Early draft	Last updated Mar 2013	None		None
Capturing audio/video	HTML Media Capture	Device APIs Working Group	Candidate Recommendation	Stable	Latest update May 2013	Growing deployment		None
	Media Capture and Streams	Joint work between Web Real-Time Communications Working Group and Device APIs Working Group	Working Draft	Stabilizing	Regularly updated	A few experimental ones		Fork me on GitHub well started
	MediaStream Recording API		Working Draft	Early draft	Updated regularly	None		None
Generation of media content	Media Source Extensions	HTML Working Group	Working Draft	Early draft	Regularly updated	Very limited		None
Image & Video analysis, modification	HTML Canvas 2D Context	HTML Working Group	Candidate Recommendation	Stable	Updated regularly	Widely deployed		Fork me on GitHub Good coverage
Audio analysis, modification	Web Audio API	Audio Working Group	Working Draft	Starting to stabilize	Regularly updated	Very limited		None

3. Device Adaptation

Mobile devices not only differ widely from traditional computers, but they also have a lot of variations among themselves, in term of screen size, resolution, type of keyboard, media recording capabilities, etc.

The Device Description Repository API is a unified server-side API that allows Web developers to retrieve data on the devices that are accessing their pages on a variety of device information database.

The Media Capture Streams API exposes some specific information on capabilities of camera and microphones to make it possible to take advantage of the large variety of media capturing devices provided on mobile phones.

CSS Media Queries offer a mechanism that allows adapting the layout and behavior of a Web page based on some of the characteristics of the device, including the screen resolution — to which Media Queries Level 4 proposes to add the availability and type of a pointing device, the ability to hover over elements, and the ambient luminosity. CSS Device Adaptation defines a set of CSS directives to define the size on which this layout should be based, relatively to the size of the underlying device — specifying what has been implemented using the <meta name="viewport"> element so far.

The proposal for a new picture element, initially developed by the Responsive Images Community Group, has been taken up by the HTML Working Group as one of the proposed extensions to HTML. It lets authors define what image to show depending on the rendering context as determined through media queries.

As a complementary approach, the srcset attribute, developed in the WHATWG and also published an extension to HTML, let Web developers define the various existing resolutions of an image, letting the browser pick the best choice for the resolution of the screen.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Device information	Device Description Repository Simple API (server-side)	Device Description Working Group (now closed)	Recommendation	finished	N/A	Limited		Good Coverage
Media Capture Capabilities	Media Capture and Streams	WebRTC and Device APIs Working Group	Working Draft	Early draft	Regularly updated	None		None
CSS-based adaptation	Media Queries	CSS Working Group	Recommendation	Finished	Latest update Apr 2012	Widely deployed		Good coverage
	Media Queries Level 4		N/A	Early draft	Regularly updated	None		None
	CSS Device Adaptation		Working Draft	Early draft	Latest update Mar 2013	Very limited		N/A
Adaptive images	The picture element	HTML Working Group	Working Draft	First draft	Regularly updated	None		N/A
	The srcset attribute		Working Draft	First draft	Regularly updated	None		None

4. 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 by offering new type of form controls that optimize 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 address book, bookmarks, etc.);
• the inputmode attribute (proposed in HTML 5.1) defines the type of textual input expected in a text entry;
• 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 <datalist> element allows creating free-text input controls coming with pre-defined values the user can select from;
• HTML 5.1 defines a mechanism for the autocomplete attribute to automatically fill input fields based on well-known data for the user.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Date and time entries	HTML5 Date and Time state of input element	HTML Working Group	Candidate Recommendation	Mostly stable, but feature marked at risk	Updated regularly	Limited		Fork me on GitHub Just started
Customized text entries (tel, email, url)	HTML5 telephone, email and URL state of input element		Candidate Recommendation	Stable	Updated regularly	Limited, but growing		Just started
Input modality	HTML 5.1 inputmode attribute		Working Draft	Early draft	Updated regularly	None		None
Input pattern	HTML5 pattern attribute		Candidate Recommendation	Stable	Updated regularly	Limited but growing		Just started
Input hint	HTML5 placeholder attribute		Candidate Recommendation	Stable	Updated regularly	Well deployed		Fork me on GitHub Started
Autocomplete for text entries	HTML5 datalist element		Candidate Recommendation	Stable	Updated regularly	Limited		Fork me on GitHub None
	HTML 5.1 autocomplete attribute values		Working Draft	Early draft	Regularly updated	None		None

5. User interactions

An increasing share of mobile devices relies 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, which Touch Events in the DOM (Document Object Model) enable. The work on that specification is now nearly finished.

Meanwhile, the Pointer Events Working Group has made good progress on an alternative approach to handle user input, Pointer Events, that allows to handle mouse, touch and pen events under a single model. This new approach is expected to replace the currently more widely deployed Touch Events.

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 in the Device APIs Working Group is making good progress.

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 independently of how the user instructed it to the device will prove beneficial to the development of device-independent Web applications. The IndieUI Events specification, developed by a joint task force between the Web Events Working Group and the Indie UI Working Group, aims at addressing this need.

Mobile devices follow their users everywhere, and many mobile users rely on them to remind them or notify them of events, such as messages: 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 Speech API Community Group is exploring the opportunity of starting standardization work around a JavaScript API that would make it possible for users to interact with a Web page through spoken commands, and a W3C Working Group charter is currently under review by the Advisory Committee.

The hardware constraints of mobile devices, and their different usage context can make mobile users experience similar barriers to people with disabilities. These similarities in barriers mean that similar solutions can be used to cater for them, making a Web site accessible both for people with disabilities and mobile devices a natural goal.

How Web Content Accessibility Guidelines (WCAG) and User Agent Accessibility Guidelines (UAAG) provide guidance on mobile accessibility — that is, making websites and applications more accessible to people with disabilities when they are using mobile phones and a broad range of other devices — is discussed in Mobile Accessibility.

WAI-ARIA provides semantic information on widgets, structures and behaviors hooks to make Web applications more accessible, including on mobile devices.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Touch-based interactions	Touch Events Specification	Web Events Working Group	Proposed Recommendation	Mostly finished	Updated regularly	Largely deployed		Started
	Pointer Events	Pointer Events Working Group	Candidate Recommendation	Stable	Updated regularly	Limited deployment		Fork me on GitHub Just started
Vibration	Vibration API	Device API	Last Call Working Draft	Mostly stable	Updated regularly	Very limited		Started
Intent-based events	IndieUI: Events 1.0	Indie UI Working Group and Web Events Working Group	Working Draft	Early draft	Last updated February 2013	None		None
Notification	Web Notifications	Web Notifications Working Group	Working Draft	Early draft	Regularly updated	Growing deployment		None
Speech-based interactions	N/A	Speech API Community Group	N/A	N/A	Regularly updated	N/A		N/A
Accessibility	Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG)	Mobile Web Best Practices Working Group & Education and Outreach Working Group	Working Group Note	Finished	N/A	N/A		N/A
	Accessible Rich Internet Applications (WAI-ARIA) 1.0	Protocols & Formats Working Group	Candidate Recommendation	Stable	Latest update Dec 2012	Growing deployment		None

6. Data storage

A critical component of many applications is 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 saving or modifying a file, while the nascent FileSystems API give access to more general file operations, including directory management. Discussions have started on whether these two latter APIs would better be implemented on top of IndexedDB.

On top of this file-based access, the Indexed Database API (IndexedDB) 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.

As more and more data need to be stored by the browser (e.g. for offline usage), it becomes critical for developers to get reliable storage space, which the proposed Quota Management API will offer to Web applications.

Likewise, as some of this data need to be encrypted, the emerging Web Cryptography API from the Web Cryptography Working Group exposes strong cryptography primitives to Web applications.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Simple data storage	Web Storage	Web Applications Working Group	Proposed Recommendation	Stable	Updated regularly	Well deployed		Complete
File reading	File API		Working Draft	Stabilizing toward LC	Regular updates	Getting well deployed		Fork me on GitHub Started
File writing	File API: Writer		Working Draft	Early draft, unsure future	Latest update Mar 2012	None		None
Filesystems operations	File API: Directories and System		Working Draft	Early draft, unsure future	Latest update Mar 2012	None		None
Database query/update	Indexed Database API		Last Call Working Draft	Stabilizing	Regularly updated	Growing		Fork me on GitHub Good coverage
	Web SQL API		Working Group Note	Abandoned	N/A	Somewhat deployed, but won’t be further deployed		N/A
Quota for Storage	Quota Management API		Working Draft	Early work	Last updated Mar 2013	Very limited		None
Encrypted storage	Web Cryptography API	Web Cryptography Working Group	Working Draft	Early work	Regularly updated	Limited		Fork me on GitHub None

7. Personal Information Management

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

For integration in browser-based Web Apps, Web Intents based approaches have been suggested, but are now stalled due to the lack of progress around that technology.

For Web apps outside of the browser, a purely programmatic approach is part of the System Applications Working Group, with work on a Contacts Manager API in progress.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Address book data	Contacts Manager API	SysApps Working Group	Working Draft	Early draft	Last updated Jun 2013	None		None
	Pick Contacts Intent	Device APIs Working Group	Working Draft	Early Web-intents based approach; stalled due to lack of progress on Web Intents	Last updated Aug 2012	None		Early draft based on previous API
Calendar data	Calendar API		Working Draft	Will likely change significantly	Last updated Oct 2012	None		None

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

Web applications can also now access orientation and acceleration data via the DeviceOrientation Event Specification.

The work on a generic Sensor API has been put on hold in favor to designing APIs for specific sensors, such as the Proximity Events API, the Ambient Light Events API or the proposed Ambient Humidity Events API.

As already mentioned in the section on multimedia, there is ongoing work on APIs to open up access to camera and microphone streams.

The opportunity for Web applications to use Near-Field Communications (NFC) mechanisms have led to the chartering of the NFC Working Group to develop a Web NFC API.

A more global access to sensors and hardware (including USB and bluetooth) is in scope for the System Applications Working Group.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Geolocation	Geolocation API	Geolocation Working Group	Proposed Recommendation	Mostly finished	Regularly updated	Widely deployed		Good coverage
Motion sensors	DeviceOrientation Event Specification		Last Call Working Draft	Stabilizing	Regularly updated	Well deployed		Started
Battery Status	Battery Status API	Device APIs Working Group	Candidate Recommendation	Stable	Updated regularly	Experimental implementations		Good coverage
Proximity sensors	Proximity Events		Last Call Working Draft	Getting stable	Regularly updated	A couple of experimental ones		Started
Ambient Light sensor	Ambient Light Events		Last Call Working Draft	Stabilizing	Regularly updated	None		Fork me on GitHub Started
Humidity sensor	Ambient Humidity Events		N/A	Unofficial draft	Last updated Aug 2012	None		N/A
Camera & Microphone streams	Media Capture Streams	Web Real-Time Communications Working Group and Device APIs Working Group	Working Draft	Stabilizing	Regularly updated	A few experimental ones		well started
NFC	Web NFC API	NFC Working Group	N/A	Very early draft	Last update June 2013	None		None

9. 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: the W3C specification (formerly known as XMLHttpRequest Level 2) completes the existing deployed 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. The work on documenting the currently deployed API (XMLHttpRequest Level 1) has been abandoned in favor of getting the new API developed more quickly.

By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects the user from having a Web site abusing their credentials and stealing their 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 triggering DOM events based on push notifications (via HTTP and other protocols.)

Early work on a Push API would allow Web applications to receive server-sent messages whether or not the said Web app is active in a browser window. As patents have been disclosed on that API, a Patent Advisory Group is being formed to assess how to make further progress possible on this work item.

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

The work on Web Real-Time Communications will also provide direct peer-to-peer data connections between browsers with real-time characteristics, opening the way to collaborative multi-devices Web applications.

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.

The network-information API addresses discovery of the network characteristics, allowing to determine for instance the rough bandwidth of the current connection. The Resource Timing API offers to measure precisely the impact of the network on the time needed to load various resources, offering another approach to adapt a Web app to its network environment.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
HTTP(s) network API	XMLHttpRequest	Web Applications Working Group	Working Draft	Still changing, but starting to stabilize	Regularly updated	Very broad for level 1 features, growing for level 2		Fork me on GitHub Well started
Cross-domain requests	Cross-Origin Resource Sharing		Candidate Recommendation	Stable	Latest update June 2012	Getting well-deployed		Well started
Server-pushed requests	Server-Sent Event		Candidate Recommendation	Stable	Regularly updated	Getting well-deployed		Fork me on GitHub Good coverage
	Push API		Working Draft	Early draft; Under review by a Patent Advisory Group	Last updated Oct 2012	None		N/A
Bidirectional connections	The WebSocket API		Candidate Recommendation	Stable	Regularly updated	Good deployment		Fork me on GitHub Well started
P2P data connections	WebRTC 1.0: Real-time Communication Between Browsers	Web Real-Time Communications Working Group	Working Draft	Early draft	Regularly updated	A few experimental ones		None
on-line state	onLine DOM state	HTML Working Group	Candidate Recommendation	Mostly stable	regularly updated	Limited		Fork me on GitHub None
Network characteristics	The Network Information API	Device APIs Working Group	Working Draft	Early draft, not getting much traction	Regularly updated	Very limited		None
	Resource Timing	Web Performance Working Group	Candidate Recommendation	Stable	Last updated Oct 2012	Very limited		None

10. Communication and Discovery

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. To communicate with unknown devices or pre-existing services, a discovery component is critical.

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. For browsers, this API would preferably be replaced by an approach based on Web Intents. For Web apps not in a browser, the System Applications Working Group is working on more complete Messaging API.

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

A joint task force of the Device APIs and Web Apps Working Groups had been looking at a mechanism called Web Intents: it aimed at closer integration of Web applications, as well as of Web applications with native applications. Some of the initial use cases for Web Intents have proved hard to expose through the regular Web browser UI, and discussions on how to properly scope that technology are on-going. In the mean time, progress on Web Intents and derived APIs has stalled.

The Networked Service Discovery API offers to discover services on the local network (such as the ones offered via DLNA), enabling mobile Web applications to integrate seamlessly with these services. An alternative approach based on Web Intents has also been under exploration.

The Web Real-Time Communications Working Group is the host of specifications for a wider set of communication opportunities:

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

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Emails, SMS and MMS with generated attachments	The Messaging API	Device APIs Working Group	Working Draft	Candidate for replacement by a Web Intents-based approach	Latest update July 2011	None		None
	Messaging API	System Applications Working Group	Working Draft	First draft	Regularly updated	None		None
Inter-app communications	HTML5 Web Messaging	Web Applications Working Group	Candidate Recommendation	Stable	Regularly updated	Well deployed		Fork me on GitHub Good coverage
Inter-app triggers	Web Intents	Device APIs Working Group and Web Apps Working Group	Working Group Note	Early draft; currently stalled	regularly updated	Experimental		None
Networked services discovery	Web Intents Addendum - Local Services		Working Draft	Very early draft; based on Web Intents that is currently stalled	Latest updated Oct 2012	None		None
	Networked Service Discovery	Device APIs Working Group	Working Draft	Early draft	Last updated Feb 2013	None		None
P2P connections	WebRTC 1.0: Real-time Communication Between Browsers	Web Real-Time Communications Working Group	Working Draft	Early draft	Regularly updated	None		None
P2P Video/Audio streams

11. 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 be shared and distributed, typically through purchases via applications stores — this is adequately addressed by packaging the application.

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; while relatively well deployed, the current approach has shown some strong limitations and the HTML and Web Applications Working Groups are considering a potentially major overhaul of the technology, likely based on NavigationController
• a JSON-based manifest format in development by the the Web Apps Working Group (as replacement for the W3C Widgets family of specifications). The System Applications Working Group is building a runtime and security model on top of that packaging.

Feature	Specification	Working Group	Maturity	Stability	Latest editors draft	Current implementations	Developers doc	Test suite
Offline Web apps	HTML5 Application Cache	HTML Working Group	Candidate Recommendation	Feature at risk (Possibly major overhaul under consideration)	Regularly updated	Well deployed		Fork me on GitHub None
	Navigation Controller	Web Applications Working Group	N/A	Early draft	Updated regularly	None		None
Packaged Web App	Web Manifest	Web Applications Working Group	N/A	N/A	Last update Jun 2013	N/A		N/A
	Runtime and Security Model for Web Applications	System Applications Working Group	Working Draft	Early draft	Regularly updated	N/A		N/A

12. 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, Resource Timing, Performance Timeline and User Timing, gives tools to Web developers for optimizing their Web applications.

The proposed work on Efficient Script Yielding offers the opportunity to Web developers to use more efficiently asynchronous programming, but has some far gained very limited traction.

The API to determine whether a Web page is being displayed (Page Visibility API) can also be used to adapt the usage of resources to the need of the Web application, for instance by reducing network activity when the page is minimized. Likewise, the Timing control for script-based animations API can help reduce the usage of resources needed for playing animations.

The battery API allows adjusting the use of resources to the current level of power available in the battery of a mobile device.

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

The Mobile Web Application Best Practices provide general advice 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	Developers doc	Test suite
Timing hooks	Navigation Timing	Web Performance Working Group	Recommendation	Finished	Regularly updated	Getting deployed		Good coverage
	Resource timing		Candidate Recommendation	Stable	Regularly updated	None		None
	Performance Timeline		Candidate Recommendation	Stabilizing	Regularly updated	None		None
	User timing		Candidate Recommendation	Stable	Regularly updated	None		Well started
Priority handling	Efficient Script Yielding		N/A	Early draft	Regularly updated	Very limited		None
Page Visibility detection	Page visibility API		Recommendation	Finished	Regularly updated	Growing deployment		Good coverage
Animation optimization	Timing control for script-based animations		Last Call Working Draft	Stabilizing	Last update Feb 2013	Well deployed		Well started
Threading	Web Workers	Web Applications Working Group	Candidate Recommendation	Stable	Regularly updated	Well deployed		Fork me on GitHub Well started
Battery Status	Battery Status Events	Device APIs Working Group	Candidate Recommendation	Stable	Updated regularly	Very limited		Good coverage
Optimization Best Practices	Mobile Web Application Best Practices	Mobile Web Best Practices Working Group (now closed)	Recommendation	Finished	N/A	N/A		N/A