Core Mobile Web Platform — 2012

Draft Community Group Specification 22 December 2012

Latest editor's draft:
Previous editor's draft:
Robin Berjon, Robineko (until September 2012)
Tobie Langel, Facebook
Jo Rabin, linguafranca.org (from November 2012)


The W3C Core Mobile Web Platform Community Group (Coremob) was established with the objective of helping to make the Web a compelling platform for developing modern mobile applications. The motivation for that is the widespread view that the Web does not represent a compelling platform for mobile applications today.

This document presents a small number of simple mobile Web application use cases. It goes on to list features that the underlying mobile Web platform needs to offer to support those use cases. It then lists technology standards (primarily W3C Recommendations) that describe those features - and also notes the current state of development of such specifications, noting also where such specification do not at present exist.

The purpose of the document is to promote understanding of which areas of Web technology are in need of development, and to encourage prioritization of those areas for specification, implementation and testing.

Other aspects of Coremob's work, which includes the collation and specification of test suites to assess conformance to referenced standards, and the specification of a framework within which such conformance testing might be assessed are referenced.

Status of This Document

This specification was published by the Core Mobile Web Platform Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

Comments on this document are not only welcomed but are actively solicited and should be made on the public-coremob@w3.org mailing list. The source code is available on GitHub.

Table of Contents

1. Introduction

Quoting from its charter:

The goal of the Core Mobile Web Platform (Coremob) Community Group (CG) is to accelerate the adoption of the Mobile Web as a compelling platform for the development of modern mobile Web applications. In order to achieve this mission, the CG brings developers, equipment manufacturers, browser vendors, operators and other relevant members of the industry together to:

  1. Agree on core features developers can depend on. These will be defined by reference to a variety of other specifications from the W3C and other standards bodies.
  2. Compile related conformance test suites.
  3. Provide to W3C (and non-W3C) groups use cases, scenarios, and other input to drive successful mobile deployment.

This document is the initial output of the Community Group. Its focus is items 1 and 3 from the CG charter above.

The following sections serve to contextualize the role of this document against the CG charter.

1.1 Audience

The primary audience for this document is standardization groups within the W3C as well as equipment manufacturers and browser vendors. The CG also intends it to be of interest to others in its chartered constituency, especially developers, for feedback on the selection of use cases and the derivation of technology requirements from those use cases.

1.2 Goals

In respect of CG Charter item 1. above, developers should be able to rely upon a set of Web technologies being consistently present and interoperably implemented across a wide range of browsers.

It is not reasonable or practical to think that all technology specifications advance at a similar rate or that all are of equally widespread utility. In addition, some depend on others. Consequently, the intention of the Community Group is to produce a number descriptions of subsets of Web platform technology specifications, which will provide for increasingly sophisticated application use cases.

This document is the first in such a series of descriptions of subsets of Web platform technologies, and provides for a limited, or base set, of mobile application use cases.

1.3 Methodology

The use cases chosen reflect a selection of popular applications that have been created using "native" techniques. Although this set of use cases is limited, and the functionality implied by them is (relatively speaking) simple, the set of functionalities is nonetheless described as being "aspirational" because it goes beyond the state of implementation by most current browsers, and indeed goes beyond the current state of specification of some of those features - see below Aspirational nature of the document for a discussion of the aspirational aspect, as construed in this revision.

Having identified features of the Web platform that are required to fulfill the use cases it is then possible to identify a set of technology specifications (or to note the absence of suitable specifications) that specify those features.

Further, having identified a set of specifications, it is then possible to identify a set of tests (or note the absence of such tests) that can be used to assess conformance with the identified specifications and also to propose a test environment in which those tests can be carried out.

1.4 Purpose of this Document

This document, as mentioned above, sets out the initial limited set of use cases; it derives Web platform technology requirements from them and it identifies technology specifications, at various states of maturity, that fulfill those requirements. It does not identify tests or test suites that match those technology specifications, which will be part of subsequent work of the group.

Since standardization work is required to complete the set of technologies required to fulfill the various use cases the document identifies, one of the purposes of the document is to point out that increased coordination between the groups that create standards would be beneficial in order to create a more coherent and pragmatically useful mobile Web application platform.

The intention of this document and subsequent editions, in regard of developers, is to solicit feedback on the use cases and on specific technology areas that are problematic, when used in a mobile context. Developers are especially encouraged to contribute to the work of the CG, since it is hoped that such participation will reduce future maintenance and development costs for them and will also provide a means by which developers' voices may be heard by constituencies that need to hear them.

1.5 Aspirational nature of the document

To be clear, the CG is not expressing the judgment that it is not possible to use the Web platform to build a wide variety of application that can be used in a mobile context. Indeed, there are applications that can be built on the Web platform that work well in a mobile delivery context. The group notes, though, that those applications are not usually specifically mobile in their use cases and tend to be similar in nature to applications that have desktop use cases as much as they have mobile use cases.

Further, the view that it is already practical to develop effective mobile Web applications is expressed with the caveat that there are many "quality of implementation" issues that developers may encounter. For example, the frame rate achievable when developing mobile games may not be sufficient, in some cases, and as another example the synchronization of playing sounds may not be adequate.

1.6 Mobile Focus

Mobile devices often have capabilities (such as a camera) or circumstances of use (such as periods off line, or frequent periods with low bandwidth for data transfer) that make mobile both a more rewarding environment for creation of applications and a more difficult environment for such implementations too.

With the rapid increase in uptake of use of mobile devices, both in developed markets and in less developed markets (perhaps as the only means of Web access in those markets), the CG believes that closing the gap between what can be achieved using Web technology on mobile and what can be achieved using "native application implementations" needs to narrow, urgently.

1.7 Other aspects of the CG's work

Other aspects of the CG's work, as mentioned in its charter, continue in parallel to the development of this document. Those activities include a "Gap analysis" of where there are existing test suites relevant to the technologies identified in this document, as well as discussion of a Test Framework within which to execute tests of the conformance of implementations of technologies identified here.

The CG's Web site and Wiki contain links to various aspects of the group's work.

1.8 Structure

The document has the following structure:

  1. Introduction

    This section, containing information about the document, its history and its scope.

  2. Use Cases

    Discusses the Use Cases that have been used to derive the requirements of Web technologies.

  3. Required Technologies

    Discusses in abstract terms what technologies are needed to support the use cases.

  4. Specifications Selected

    Discusses the specifications selected to implement "required technologies".

  5. Missing Specifications

    Discusses technologies needed but not specified.

  6. Quality of Implementation

    Discusses aspects of implementation of some of the selected technologies

2. Use cases

The basis of selection for the use cases is a survey of the top native applications found in mobile application stores. The requirements of each applications were assessed and prioritized depending on how hard bringing that technology to the Open Web Platform would be, and how many applications it would unlock. For example, an API to read the battery status was ruled out because there was only one application relying on it… and its only purpose was to provide information on the battery status (something best done at the OS level anyway). Support for WebGL [WEBGL] was similarly ruled out because only a very small number of games (3D games are rarer on mobile then they are on desktop) were unlocked by it, and it was known to be challenging to implement.

To this basis we added the obvious interoperability requirements with existing Web content and features web developers are accustomed to rely on.

The following use cases were designed to illustrate the requirements defined above and listed in section 3. Derived Requirements and are by no means exhaustive.

2.1 Take pictures in a remote area without network coverage

Jenna is hiking in a remote area without network coverage. She takes high quality pictures using a Web application. The pictures are stored locally. She decides to post-process some of the pictures she took by applying ready-made filters. She is able to continue taking pictures while the filters are applied. When she returns to an area with better network coverage, her pictures are updated to a remote server. While the upload is going on in the background she can continue taking pictures or can browse her previous shots to select the ones she wants to share with her friends.

Derived requirements: Req. 6, Req. 8, Req. 9, Req. 10, Req. 13, Req. 15, Req. 17, Req. 23.

2.2 Record voice memos

While on his morning commute, John records a short voice memo using a Web application. As he is offline, the audio file is stored locally. When he reaches the office, the audio file is asynchronously uploaded to the application's servers where it is transcribed.

Derived requirements: Req. 6, Req. 8, Req. 9, Req. 13, Req. 16, Req. 23.

2.3 Play a 2D Game

Fantastic Rafaela Sis' is a platform game the goal of which is to save an imprisoned prince. This is done by navigating a character, Rafaela, across various levels from left to right. Each levels consist of a series of obstacles and enemies that the player has to avoid (by jumping over, shooting, etc). The character is controlled by tilting the device. Consequently, the game must be locked in landscape mode to avoid auto-rotation of the viewport interfering with the game play. It has a soundtrack per level and various sound effects.

Derived requirements: Req. 11, Req. 12, Req. 18, Req. 19, Req. 21.

2.4 Find the nearest subway station

Jo uses public transportation to visit his clients scattered around town. In order to find his way around he relies on a Web application that is able to locate him on a map, display the closest subway station and indicate in which direction he should walk to find it.

Derived requirements: Req. 21, Req. 22.

2.5 Read an online magazine

Jane likes to read the news on her commute to work. She's uses a Web application on her tablet that she updated before leaving home. While on the subway, she's able to read the daily news, watch a video of the highlight's of yesterday's football match and listen to the magazine's weekly political podcast. Jane is able to navigate through the application using the back and forward button of her browser. And when she finds an article she would like to share with her friend, Sam, she is able to copy and paste the URL into an email which she'll send when arriving at work.

Derived requirements: Req. 4, Req. 6, Req. 7, Req. 13, Req. 14, Req. 19, Req. 20, Req. 24.

2.6 View a regular website

Anette is using her mobile device to access her bank's website. Although her bank has a dedicated native application and a mobile version of its site, the information she's looking for is only available on the main site. She's nonetheless able to consult it because her mobile device supports the same set of Web standards her desktop browser does, and is capable of displaying that information despite the difference in screen size and pixel density.

Derived requirements: Req. 1, Req. 2.

2.7 Browse a responsive website

John is en route for his dentist appointment. He's late, forget to write down the dentist's phone number, and has very poor network connection. Thankfully, the dentist has a responsive website which displays very quickly on John's mobile device. He's able to quickly find the dentist's phone number and call him.

Derived requirements: Req. 1, Req. 2, Req. 3, Req. 24.

2.8 Bookmarking a Web application

Paul uses the same Web mail client on various devices and user agents. He would like to bookmark it so that it is easily recognizable across his different devices yet blends in with how other applications are portrayed in the given environment.

Derived requirements: Req. 5.

3. Derived Requirements

The following requirements are derived from the use cases described in section 2. Use cases.

3.1 General

Req. 1: A User Agent must support technology commonly available on desktop browsers, so that websites and applications designed for desktop are still usable on mobile.

Req. 2: The User Agent must be able to display content specifically targeted at mobile devices.

Req. 3: It must be possible to request for the User Agent to download and display different content depending on device or User Agent properties such as screen size, pixel density, etc.

Req. 4: The User Agent must support rich typography including using downloadable fonts.

3.2 App-specific

Req. 5: It must be possible to provide the User Agent with meta-data a such as the application's name, icon, etc.

Req. 6: It must be possible to make an application available offline.

Req. 7: The User Agent must allow the application developer to define URLs for chosen resources (for example for bookmarking or sharing) and to manipulate session history for single page applications.

Req. 8: It must be possible for Web application user interfaces to occupy all the screen space yet adapt to different screen sizes without leaving unused space or overflowing.

Req. 9: It must be possible for Web application user interfaces to transition smoothly from one state to another.

Req. 10: It must be possible to scroll smoothly through a large body of content.

Req. 11: A Web application might be designed to be used strictly in portrait or landscape mode. It must be possible to signal this preference to the User Agent.

Req. 12: It must be possible for an application to signal to the User Agent that it wants to operate fullscreen and not inside of the browser's chrome.

3.3 Storage

Req. 13: It must be possible to store files locally and retrieve them without requiring further permission from the user.

Req. 14: It must be possible to asynchronously store and retrieve large, structured persistent data sets.

3.4 Multimedia

Req. 15: It must be possible to take pictures using the device's camera. This must be done in such a way that the user's security and privacy is respected.

Req. 16: It must be possible to record audio clips using the device's microphone. This must be done in such a way that the user's security and privacy is respected.

Req. 17: It must be possible to programmatically manipulate a picture so as to crop it, apply filters to it, etc. and save the result of these manipulations. This must not block the UI thread.

Req. 18: It must be possible to draw multiple animated sprites at 30FPS in fullscreen mode.

Req. 19: Multiple sound files must be able to play simultaneously with minimal latency.

Req. 20: The User Agent must support video playback.

3.5 Sensors

Req. 21: It must be possible to register to receive updates when the position of the device changes.

Req. 22: It must be possible to obtain the device's current geographic coordinates provided the user consents to sharing those.

3.6 Networking

Req. 23: It must be possible to asynchronously upload files to remote server on different origins. Ideally, uploads should continue even if the user navigates to a different page.

Req. 24: mailto:, tel:, sms: and mmsto: URL schemes should allow the user to respectively send an email, make a phone call, send an SMS or send an MMS using the appropriate application to do so.

4. Specifications which address the derived requirements

This section lists existing specifications which address the requirements expressed in section 3. Derived Requirements and notes their current state of standardization (progress along W3C Rec Track is noted using conventional abbreviations).

The document Standards for Web Applications on Mobile: current state and roadmap is regularly updated to reflect current status both of standardization and of implementation of many of the same standards.


The CG has had frequent cause to discuss whether or not it needs to make reference to the whole of a referenced specification. In the course of such discussions it has frequently re-iterated that it is not its role to cherry-pick parts of the specifications produced by other groups. Equally, however, it has frequently noted that its use cases require only sub-sections of referenced specifications. The CG has observed that the WGs responsible for producing such specifications might choose to subset their work to advance speed of specification, modularity of testing and so on.

4.1 Markup

CategorySpecificationStatusRequirements Addressed
GeneralHTML5 [HTML5]CR Req. 1, Req. 6, Req. 7, Req. 19, Req. 20
HTML Media Capture [HTMLMEDIACAPTURE]WD Req. 15, Req. 16
Scalable Vector Graphics (SVG) 1.1 (Second Edition) [SVG11]REC Req. 1, Req. 3
CSS Device Adaptation [CSS-ADAPTATION] (as specified through a meta viewport element)WD Req. 2, Req. 3.

4.2 Style

CategorySpecificationStatusRequirements Addressed
GeneralCSS 2.1 [CSS21]RECReq. 1
Processing CSS Values [CSS3VAL] 1CR Req. 1
CSS Media Queries [CSS3-MEDIAQUERIES]REC Req. 1, Req. 2, Req. 3
CSS Selectors Level 3 [SELECT]REC Req. 1
Graphical CSS Backgrounds and Borders [CSS3-BG]CR Req. 1
CSS Image Values and Replaced Content [CSS3-IMAGES]CR Req. 1
Layout CSS Flexible Box Layout [FLEXBOX]CR Req. 8
CSS Transforms [CSS3-TRANSFORMS]WD Req. 1
Typography CSS Fonts [CSS3-FONTS]WD Req. 3, Req. 4
WOFF [WOFF]REC Req. 3, Req. 4
CSS Text [CSS3TEXT] 2WD Req. 4
Animations and Transitions CSS Animations [CSS3-ANIMATIONS]WD Req. 1
CSS Transitions [CSS3-TRANSITIONS]WD Req. 9

1. Most of the common content of CSS Values is already included in CSS 2.1. There are some features that would be welcomed additions, notably calc(), rem unit, but also some that don't seem to have a lot of traction (e.g. cycle()).

2. The requirements are only for a small subset of CSS Text, mainly text-shadow. Like CSS Values, a lot what is of interest is already covered by CSS 2.1.

4.3 Scripting

CategorySpecificationStatusRequirements Addressed
GeneralECMAScript, Edition 5.1 [ECMA-262-51]N/A Req. 1
Selectors API Level 1 [SELECTORS-API]PR Req. 1
Touch Events version 1 [TOUCH-EVENTS]CR Req. 2
CSSOM View [CSSOM-VIEW]WD Req. 1, Req. 2
Storage Web Storage API [WEBSTORAGE]CR Req. 1
Indexed Database API [INDEXEDDB]WD Req. 13, Req. 14
File API [FILE-API]WD Req. 15, Req. 16, Req. 17, Req. 13, Req. 23
Quota Management API [QUOTA-API]WD Req. 6, Req. 13, Req. 14
Networking XMLHttpRequest API [XMLHTTPREQUEST]WD Req. 1, Req. 23
Web Messaging API [POSTMSG]CR Req. 1 Req. 23
Web Workers API [WEBWORKERS]CR Req. 1, Req. 23
Sensors Geolocation API [GEOLOCATION-API]PR Req. 22
DeviceOrientation Event [DEVICE-ORIENTATION]WD Req. 21
Multimedia Canvas2D API [CANVAS-2D]CR Req. 17, Req. 18
Timing control for script-based animations API [ANIMATION-TIMING]WD Req. 18

4.4 Network

CategorySpecificationStatusRequirements Addressed
General HTTP 1.1 [HTTP11]N/AReq. 1
Cross-Origin Resource Sharing [CORS]WDReq. 23
The data: URI scheme [RFC2397]N/A Req. 1
The mailto: URI scheme [RFC6068]N/AReq. 24
The tel: URI scheme [RFC3966]N/AReq. 24
The sms: URI scheme [RFC5724]N/AReq. 24
The mmsto: URI scheme [OMA-URI-SCHEMES]N/AReq. 24

5. Requirements only partially addressed by existing specifications

The following requirements are only partially addressed by existing specifications: Req. 1, Req. 2, Req. 6, Req. 3.

There is ongoing work to address each of those requirements within W3C as detailed below. The CG encourages these efforts.

5.1 Pointer events

While Req. 1 and Req. 2 are generally addressed by a number of existing specifications, there is one area which is still problematic: user input. Touch-enabled devices delay click inputs (presumably to handle long and double taps). While there exists different solutions to remove that delay, developers tend to rely instead on touch events [TOUCH-EVENTS]. In turn, this creates content which doesn't work properly when used with a different kind of input mechanism. In order to address this situation, the Pointer Event WG was formed and has published a first Working Draft [POINTER-EVENTS].

5.2 Offline

Currently, Application Cache is the only Web technology designed to address Req. 6. Its issues have already been exhaustively documented elsewhere. This technology is very complex, poorly understood, and hard to use. It is also marked at risk in the HTML5 specification.

Recently, the WebApps WG has decided to take over this work with the blessing of the HTML WG. In parallel, the Fixing Application Cache CG is collecting case studies, use cases and requirements.

5.3 Responsive Images

While a lot has been done to address Req. 3, notably through media queries, there is no set solution for responsive images to date. The Responsive Images CG has made a proposal (The picture element), and so has the HTML WG (The srcset attribute). The HTML WG is set to determine the merit of both solutions and examine whether they should be combined.

6. Unaddressed requirements

The following requirements aren't addressed by existing specifications: Req. 5, Req. 10, Req. 11, and Req. 12.

However, there is early work going on to address some of these.

6.1 Application meta-data

The multitude of existing formats to describe application meta-data (Req. 5) have been listed elsewhere already. The WebApps WG is chartered to work on this and has two related specs: Widget Packaging and Configuration [WIDGETS] (which has had little traction among the main vendors), and Web Application Manifest Format and Management APIs [WEBAPPS-MANIFEST-API] (which is still an early Editor's draft).

6.2 Momentum and infinite scrolling

Smooth and stutter-free scrolling is first and foremost a QoI issue. However, the requirements (maintaining 60fps while possibly altering the DOM) are sufficiently taxing that they are difficult to meet on mobile devices, even on high-end ones. Some very recent work attempts to cater to this issue.

6.3 Screen Orientation

A specification to fulfill Req. 11 is a deliverable of the WebApps WG. A first public Working Draft [SCREEN-ORIENTATION] was recently publish by the WG.

6.4 Chromeless Mode

While within the scope of the WebApps WG's charter, no work that would address Req. 12 is currently ongoing.

7. Quality of Implementation

The CG notes that functional conformance to specifications is sometimes insufficient to create a functional user experience of Web applications. There are many areas in which non-functional (or QoI) requirements have been noted, relating to speed, time related consistency (smoothness) and so on.

The group's work to date has yielded the following particular points of note:

7.1 QoI of the audio element

Implementors should pay particular attention to the quality of implementation of the audio element. audio elements are commonly used in games to play background music and sound effects. It is recommended that implementations support playing 8 audio files in parallel without audible artifacts and provide sub 10ms latency.

7.2 Performance of the canvas element

Implementors should pay attention to the performance characteristics of the canvas element which is particularly well suited for the development of 2D and isometric games. In order to meet the expectations of users, implementations should be capable of running such games at 30fps in full-screen mode.

7.3 Performance of scrolling, transitions, and animations

Smooth scrolling, transitions, and animations are key to delivering great user experiences. Implementations should aim to render these at 60fps.

7.4 Dedicated form controls

On mobile devices content input is often tedious. Implementors should therefore implement dedicated form controls where appropriate (for example, displaying a numerical keypad for inputs of type tel).

8. Conformance

This document does not express any conformance requirements. Conformance to this document would consist of conforming to the technology standards it identifies, however, some of the technology standards it identifies have not advanced to a sufficient state of maturity to be capable of having conformance requirements.

A. Acknowledgements

Thanks to Lars Erik Bolstad, Giridhar Mandyam, and Marcos Cáceres for their help collecting use case and requirements.

Thanks to Matt Kelly for initiating and driving the research on the requirements of top native applications, and to all those who contributed to it, particularly WonSuk Lee and Ming Jin.

Thanks also to all members of the Coremob CG.

B. References

B.1 Informative references

James Robinson; Cameron McCormack. Timing control for script-based animations. URL: http://www.w3.org/TR/animation-timing/
Ian Hickson. HTML Canvas 2D Context. 25 May 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2dcontext/
Anne van Kesteren. Cross-Origin Resource Sharing. 17 March 2009. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2009/WD-cors-20090317
Rune Lillesveen. CSS Device Adaptation. 23 January 2012. Editor's Draft. (Work in progress.) URL: http://dev.w3.org/csswg/css-device-adapt/
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification.. W3C Recommendation. URL: http://www.w3.org/TR/CSS21/
Dean Jackson (Apple Inc); David Hyatt (Apple Inc); Chris Marrin (Apple Inc). CSS Animations. 03 April 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/css3-animations/
Elika J. Etemad; Bert Bos; Brad Kemper. CSS Backgrounds and Borders Module Level 3. URL: http://www.w3.org/TR/css3-background/
John Daggett (Mozilla). CSS Fonts Module Level 3 URL: http://www.w3.org/TR/css3-fonts
Elika J. Etemad, Tab Atkins Jr.. CSS Image Values and Replaced Content. 17 April 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/css3-images/
H. Lie, T. Çelik, D. Glazman, A. van Kesteren. Media Queries URL: http://www.w3.org/TR/css3-mediaqueries/
Simon Fraser; Dean Jackson; David Hyatt; Chris Marrin; Edward O'Connor; Dirk Schulze; Aryeh Gregor. CSS Transforms. URL: http://www.w3.org/TR/css3-transforms/
Dean Jackson; David Hyatt; Chris Marrin; L. David Baron. CSS Transitions. 03 April 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/css3-transitions/
Tantek Çelik; Chris Lilley; L. David Baron. CSS Color Module Level 3. 07 June 2011. W3C Recommendation. URL: http://www.w3.org/TR/css3-color
Elika J. Etemad; Koji Ishii. CSS Text Level 3. 19 January 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/css3-text/
Chris Lilley; Håkon Wium Lie. CSS3 Values and Units. 08 March 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/css3-values/
Anne van Kesteren. CSSOM View Module. 22 February 2008. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2008/WD-cssom-view-20080222
Steve Block, Andrei Popescu. DeviceOrientation Event Specification. 1 December 2011. Last Call Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-orientation-event-20111201/
Anne van Kesteren; Aryeh Gregor; Ms2ger. DOM4. URL: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html/
ECMAScript Language Specification, Edition 5.1. June 2011. URL: http://www.ecma-international.org/publications/standards/Ecma-262.htm
Arun Ranganathan; Jonas Sicking. File API. 20 October 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-FileAPI-20111020/
Tab Atkins Jr.; Elika J. Etemad; Alex Mogilevsky. Flexible Box Layout Module. 12 June 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/css3-flexbox/
Andrei Popescu. Geolocation API Specification. 22 December 2008. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2008/WD-geolocation-API-20081222/
Ian Hickson; David Hyatt. HTML5. 29 March 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/html5
Anssi Kostiainen; Ilkka Oksanen; Dominique Hazaël-Massieux. HTML Media Capture. 29 May 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-html-media-capture-20120529/
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June 1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt
Nikunj Mehta, Jonas Sicking, Eliot Graff, Andrei Popescu, Jeremy Orlow. Indexed Database API. April 2011. Working Draft. (Work in progress.) URL: http://www.w3.org/TR/IndexedDB/
URI Schemes for the Mobile Applications Environment. Approved Version 1.0 26 Jun 2008. URL: http://www.openmobilealliance.org/Technical/release_program/docs/URI_Schemes/V1_0-20080626-A/OMA-TS-URI_Schemes-V1_0-20080626-A.pdf
Jacob Rossi, Matt Brubeck. Pointer Events. 11 December 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/pointerevents/
Ian Hickson. HTML5 Web Messaging. URL: http://dev.w3.org/html5/postmsg
Kinuko Yasuda. Quota Management API. 3 July 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/quota-api/
L. Masinter. The "data" URL scheme. August 1998. Internet RFC 2397. URL: http://www.ietf.org/rfc/rfc2397.txt
H. Schulzrinne. The tel URI for Telephone Numbers December 2004. Internet RFC 3966. URL: http://www.ietf.org/rfc/rfc3966.txt
E. Wilde, A. Vaha-Sipila. URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS). January 2010. Request for Comments. URL: http://www.ietf.org/rfc/rfc5724.txt
M. Duerst; L. Masinter; J. Zawinski. The 'mailto' URI Scheme. October 2010. Internet Proposed Standard RFC 6068. URL: http://www.ietf.org/rfc/rfc6068.txt
Mounir Lamouri. The Screen Orientation API. 06 December 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/screen-orientation/
Daniel Glazman; et al. Selectors Level 3. 10 March 2009. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2009/WD-css3-selectors-20090310
Lachlan Hunt; Anne van Kesteren. Selectors API. 14 November 2008. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2008/WD-selectors-api-20081114
Erik Dahlström; et al. Scalable Vector Graphics (SVG) 1.1 (Second Edition). 16 August 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-SVG11-20110816/
Matt Brubeck; Sangwhan Moon; Doug Schepers; Touch Events version 1 URL: http://www.w3.org/TR/touch-events
Anant Narayanan. Web Application Manifest Format and Management APIs. W3C Editor's Draft. (Work in progress.) URL: http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html
Chris Marrin (Apple Inc.) WebGL Specification, Version 1.0 , 10 February 2011 URL: https://www.khronos.org/registry/webgl/specs/1.0/
Ian Hickson. Web Storage. 10 September 2009. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2009/WD-webstorage-20090910/
Ian Hickson. Web Workers. 1 September 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-workers-20110901/
Marcos Cáceres. Widget Packaging and XML Configuration. W3C Recommendation. URL: http://www.w3.org/TR/widgets/
Jonathan Kew, Tal Leming, Erik van Blokland. WOFF File Format 1.0. 04 August 2011. Candidate Recommendation. URL: http://www.w3.org/TR/WOFF/
Anne van Kesteren. The XMLHttpRequest Object. 15 April 2008. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415