Development of this document happens on GitHub. Please file well-scoped issues and send pull requests directly on GitHub. Please send comments to the mailing list as described below.
This specification describes the core set of technologies that define the baseline platform for mobile Web applications to target. It does not create any new technology but rather syndicates them into a globally coherent view of the Web platform as available on mobile devices.
This is Level 0, the first iteration. As the platform evolves and new technologies become broadly available, additional levels, which are guaranteed to remain backwards compatible, will be layered on top of the present one.
This document is not mobile-specific, but rather mobile-scoped. This is to say that there is no part of its content that applies solely to mobile terminals, or to any particular device class; all of its recommendations work and apply equally well across the entire Web. It does however focus on addressing issues commonly found in developing Web applications on mobile devices.
It does so by taking a platform view of Web application development in the mobile ecosystem. As things currently stand, there is a large body of diverse specifications at varied degrees of maturity that are supported on mobile devices. These specifications are designed to work together, but also to be implementable separately. Because of this, and because of the great variety of vendors involved in the mobile platform, we currently have an ecosystem in which different vendors have elected to support different subsets of the complete group of technologies currently in development. This fragmentation makes it particularly difficult for developers to know which features they may rely on in creating applications, which in turn hurts the development of the entire Web ecosystem.
By taking the platform view, this document defines a common baseline that is expected to be universally available to developers (or sufficiently close to that to be useful). It does not replace any existing specification, be it considered stable or in continuous development. Its only goal is to define a baseline target platform that vendors can align on.
In no case should this be considered a cap on the features that an application may use — developers are considered to know what they are doing and to be naturally free to use any functionality not included in this core baseline according to their own judgement. It is not intended to be the final word on the Web platform either, rather the intent of the group in charge of this document is to produce multiple levels in quick succession that will layer atop one another as parts of the platform that are reliably usable stabilise sufficiently and can be driven to adoption and deployment. For this first level, we have started off the intersection of what is available in the most popular mobile platforms. Future levels will assume more of a driving role.
Our focus in writing this series of documents is entirely driven by developer needs. There may at times be some corner case issues that would require deep exegesis of this or that specification were we to address them. But unless a demonstrated interoperability issue can be exposed that concerns a real-world use case for such corner case behaviours, such exegesis will not take place and we will gladly ignore these darker corners. At times some choices may be messy, or even against known best practices. But if they are the most pragmatic option, they will be chosen.
This section describes requirements for markup languages and related features.
User agents MUST support the following parts from HTML 5 [[!HTML5]]:
Historyinterface and the
For video, user agents MUST support the ITU-T VCEG H.264 codec.
For audio, user agents MUST support MPEG-2 Audio Layer III.
Obviously the two above taken on their own don't give you much. Into how much detail do we need to go?
Not certain that AppCache is Level 0.
Codecs are evil. Thoughts?
User agents MUST support CSS Device Adaptation [[!CSS-ADAPTATION]] as specified through a
Not sure that this is clear enough, and it probably requires more than what is supported.
This section defines which support for styling with CSS is required at this level.
It is particularly important to note that at this level and depending on future decisions quite possibly at this level only a user agent is considered to support the features required in this section even if they are only available behind vendor prefixes.
User agents MUST support CSS 2.1 [[!CSS21]]. Implementers should pay special attention to:
User agents MUST support CSS Media Queries [[!CSS3-MEDIAQUERIES]] for the following media features: width, height, device-width, device-height, and orientation (including their min-/max- variants where applicable).
User agents MUST support CSS Backgrounds and Borders [[!CSS3-BG]].
User agents MUST support CSS Animation [[!CSS3-ANIMATIONS]].
User agents MUST support CSS Color [[!CSS3COLOR]], specifically the
and RGBA and HSLA values.
User agents MUST support CSS Fonts [[!CSS3-FONTS]]. Both the TTF and OTF formats are required.
User agents MUST support CSS 2D Transforms [[!CSS3-2D-TRANSFORMS]].
User agents MUST support CSS Transitions [[!CSS3-TRANSITIONS]].
User agents MUST support CSS User Interface [[!CSS3UI]], specifically
User agents MUST support Flexible Box Layout [[!FLEXBOX]].
User agents MUST support CSS Multi-column Layout [[!CSS3COL]].
User agents MUST support CSS Image Values and Replaced Content [[!CSS-IMAGEVAL]] for gradients.
User agents MUST support CSS Text [[!CSS3TEXT]], notably the
overflow-wrap, either naming is acceptable) and
I doubt that we want all of CSS Text just yet.
User agents MUST support the
rem unit from CSS Values [[!CSS3VAL]].
User agents MUST support PNG alpha transparency.
This section defines which scripting support in language and APIs are required at this level.
User agents MUST support ECMAScript ed3 [[!ECMA-262]] in full, plus all the parts from ed5 that
can be shimmed, including native JSON. Notably, user agents MUST support callable host objects
The "can be shimmed" criterion seems like a good one, but it ought to be more precisely defined. If you implement JS in JS you can shim pretty much anything.
User agents MUST support the Canvas2D API [[!CANVAS-2D]].
User agents MUST support the Geolocation API [[!GEOLOCATION-API]].
User agents MUST support the DeviceOrientation Event [[!DEVICE-ORIENTATION]].
User agents MUST support Touch Events version 1 [[!TOUCH-EVENTS]].
Need to check if Touch isn't for Level 1.
User agents MUST support the Web Messaging API [[!POSTMSG]].
User agents MUST support the XMLHttpRequest API level 2 [[!XMLHTTPREQUEST2]], notably support for Progress Events [[!PROGRESS-EVENTS]].
We require Progress Events which are in XHR level 2, but all the rest of XHR2 is for CoreMob level 1.
User agents MUST support the Selectors API level 2 [[!SELECTORS-API2]].
User agents MUST support the Web Storage API [[!WEBSTORAGE]].
Obviously there are quite a few more. DOM4?
This section defines which networking protocols are required at this level.
User agents MUST support HTTP 1.1 [[!HTTP11]].
I would assume that such support may be partial at best for some of the more obscure parts of HTTP. Do we care? Are there known interoperability issues here?
User agents MUST support Cross-Origin Resource Sharing [[!CORS]].
What do we need to specify for HTTPS/SSL/TLS?
User agents SHOULD support dispatching the following URI schemes to the appropriate applications
User agents MUST support