Goals
This document summarizes technologies developed or under development in W3C or elsewhere, and that can be used to build a particular type of applications (e.g. media applications, games) or to promote a particular aspect of application development (e.g. security). The document is organized in pages that present specific features per deployment status and explain their relevance to the underlying theme. Tables at the end of sections summarize the standardization and implementation status of specifications that define features presented in the text.
Features are mostly presented in isolation with minimal text. This is on purpose to ease moving features around as they progress on the standardization front and get deployed in implementations.
Audience
This document is mainly targeted at developers of Web applications willing to understand the status of the Web platform for particular vertical needs (e.g. publishing) or on particular devices (e.g. mobiles). Device manufacturers may also find valuable information about features that their products should support.
This document answers questions such as:
- Which technologies are available today across browsers?
- Which technologies should be available tomorrow?
- What are the features that being explored and that could lead to new technologies later on?
- Are there technical gaps in a given field for which there are no active standardization work today?
Understanding tables
Tables at the end of sections summarize information about individual features. Columns displayed may depend on the table. Features of interest come with a name, one or more specifications (or individual features within specifications) that enable this feature, and details about each specification.
Maturity levels
The maturity of a feature refers to its standardization status.
Maturity | Meaning |
---|---|
Defined in an Editor's Draft, not yet published officially anywhere. Feature should not be considered stable and possible implementations can still change substantively before the feature stabilizes. | |
Defined in a W3C Working Draft. Feature should not be considered stable and possible implementations can still change substantively before the feature stabilizes. | |
Defined in a W3C Candidate Recommendation. Feature may be considered stable but could still change based on implementation experience. Implementations may not be fully interoperable. | |
Defined in a W3C Proposed Recommendation. Feature is undergoing a final review by W3C Members. It is stable and existing implementations should be mostly interoperable. | |
Defined in a W3C Recommendation. Feature is stable and existing implementations should be mostly interoperable. | |
Defined in a WHATWG Living Standard. Stability and interoperability depend on the feature being considered and are usually noted in the specification itself. | |
Defined in a W3C Note. Publication as a Note either indicates that the feature is informational in nature (e.g. guidelines, techniques, best practices), or that work on the feature has been discontinued for some reason. | |
Feature was part of a Web standard, but implementation and usage are no longer recommended for some reason (e.g. privacy concerns, security issues, better mechanism available). |
Implementation info
For features that target Web browsers, the "Current implementations" and "Implementation intents" columns display known implementation status in main browsers. The information is structured per implementation status, which can be one of:
- Shipped: the feature is supported in the browser and can be used right away.
- Experimental: the feature is planned for an upcoming version of the browser, and can be tried out in nightly builds of the browser. The feature may also be behind a flag, or it may require the use of a prefix.
- In development: the feature is being developed but is not yet available.
- Under consideration: the feature is not yet in development but is being considered for a future version of the browser.
The tables may contain implementation information about the following browsers:
Icon | Browser name |
---|---|
Main browser engines | |
Chrome | |
Microsoft Edge | |
Firefox | |
Safari | |
Based on the main browser engines | |
Baidu Browser | |
Opera | |
QQ Browser | |
Samsung Internet | |
UC Browser |
Badges overlaid on top of browser icons convey additional implementation information:
Badge | Meaning |
---|---|
Implementation information applies to the desktop version of the browser. | |
Implementation information applies to the mobile version of the browser. Note that the implementation info only applies to mobile versions where the browser uses its own layout engine (e.g. "Firefox for Android", or "Safari for iOS"), not to mobile versions where the browser uses another layout engine (e.g. "Firefox for iOS"). In other words, given the implementation information available today, the mobile badge means "iOS" for Safari, and "Android" for all other browsers. |
|
Implementation information applies both to the desktop and mobile versions of the browser. | |
Some flag needs to be set in order to enable the feature in the browser. That flag may be a preference flag that the user may set in parameters, a compile flag that must be set before compiling the browser, or a runtime flag that must be set before starting the browser. | |
A prefix must be used to access the feature. For instance, in Firefox, this usually means adding something like a -moz- prefix for CSS properties and a moz prefix to API functions. |
On devices that support hovering, a tooltip that summarizes the implementation information is displayed when the user moves over a browser icon.
Under the hoods, the implementation information is being gathered from the following platform status sources:
- Can I Use?
- Chrome Platform Status
- Microsoft Edge web platform features status and roadmap
- WebKit Feature Status
Clicking on a browser icon in an implementation should take you to the right page on the platform status Web site that provided the implementation information.
The absence of implementation information for a given browser usually means that the feature is not supported at all, and that it is not being developed for now in that browser. However, it may also mean that the implementation information is not yet available. If you notice missing or incorrect implementation info, please create an issue on the GitHub repository of this document.
Change History
April 2018
The April 2018 snapshot introduces a number of features that were missing from the January 2018 snapshot. Content-wise, the following changes were made:
- Exploratory work
- Mention the Web Share API and the Web Share Target API in Application Lifecycle
- Mention Requesting/Revoking permissions specifications in Security and Privacy
- Mention Feature Policy in Security and Privacy
- Mention Element Queries in Device Adaptation
- Replace WebVR by WebXR and mention polyfill in Media
- Technologies in progress
- Fix Proximity Sensor implementation status in Sensors and Local Interactions
- Fix Ambient Light API implementation status in Firefox and Edge in Sensors and Local Interactions
- Fix Presentation API implementation status in WebKit in Media
- Mention the CSS
font-display
property and update text on downloadable fonts in Graphics and Layout - Mention the Streams specification in Network and Communications
- Mention Payment Method Identifiers and Payment Method Manifest in Payment and Services
- Well-deployed technologies
- Mention CSS Grid Layout in Graphics and Layout
- Mention the CSS
box-sizing
property in Graphics and Layout - Move
requestIdleCallback
to the well-deployed section in Performance and Tuning - Update text on WOFF (WOFF 2.0 was recently published as a W3C Recommendation), mention variable fonts in Graphics and Layout
- Refine accessibility part in User Interaction and rename the category to promote accessibility
- Mention the
passive
flag for event listeners in Performance and Tuning - Move the Date and time entries to the well-deployed section but warn about partial implementations in Forms
- Discontinued features
- Mark humidity, thermometer, barometer proposals as discontinued in Sensors and Local Interactions
- Mark appcache as discontinued in Application Lifecycle
The implementation info rendered in tables at the end of each section now embeds information about mobile browsers, and warns when a prefix is required or when a flag must be set to use a feature. Such features are also now consistently flagged as "Experimental" throughout the tables. Implementation information about additional browsers (Baidu, Opera, QQ, Samsung Internet, UC Web) can now be displayed from a dropdown menu. By default, tables will only display information about main browsers (Chrome, Microsoft Edge, Firefox, Safari), because this information is more up-to-date and reliable (information for other browsers may still be outdated or incorrect in some cases).
This version also features a series of User Interface improvements to improve the readability and accessibility of the pages.
Under the hoods, the roadmap framework has been almost entirely re-written to ease Roadmap authoring, and the publication of future snapshots. For instance, the extraction of information about W3C, WHATWG, and IETF specifications should now be automatic in most cases. Please refer to the documentation for details.
January 2018
The January 2018 snapshot is a major overhaul of the previous mobile roadmap, published until August 2015. Categories have remained vastly intact, but the new version comes with a new lightweight design, and the contents of the pages have been significantly updated to follow the evolution of the Web platform in the past few years.
The roadmap is published in English and Chinese.
Some content may still be missing or incomplete. Among other things, implementation information only targets desktop browsers and is known not to be perfectly correct.