NOTE: This document is mainly historical at this point.

Achieving maintenance and future progress of HTML

The goal of this plan is to improve the tone and participation at W3C so that we achieve interoperability around HTML and continue to enhance the specification.

That can be achieved in 4 phases:

  1. Incubating new ideas
  2. Efficient data-driven standards work
  3. Interoperability
  4. Maintenance (aka actual interoperability)

This plan proposes to create one Community Group to incubate ideas, and reshape the Working Groups to achieve interoperability.

Incubating new ideas

There is one Community Group, called the Web Platform Incubator Community Group (Web Platform ICG). Its mission is to attract, foster, and incubate ideas and proposals around the Web Platform, by facilitating communication with developers at large or by using data-driven metrics to identify common patterns that warrant first class support in the Web Platform. If the Web Platform ICG works with consensus, it will significantly reduce the effort to transition from CG to W3C Recommendation.

The W3C Team and Leadership of the Community and Working Groups should ensure proper transitioning of ideas towards the standardization track, while also ensuring proper continuity in participation.

Note that the creation of the Web Platform ICG would not preclude new ideas from being discussed in other Community or Working Groups. It simply provides an easy forum with the Community already present without the need to create one more new Community Group if one doesn't wish to.

From ideas to standards work

Once a proposal becomes mature enough to justify formal standardization, it becomes the mission and responsibility of a Working Group to ensure proper acceptance, through consensus, wide reviews, data-driven analysis, and technical merit. A proposal may become ready for standardization efforts because of implementation experience or broad support.

Supporters of the proposal should perform an "Intent to Migrate" assessment, outlining use cases, as well as implementation considerations, security, privacy, accessibility, and internationalization impacts. It is the role of the proper Working Group (HTML, CSS, WebApps, etc.) to evaluate such assessment before starting a standardization effort.

CG Considerations

Contributions will be need to be tracked to ensure proper commitments. As such, we'll need the following setup:

Efficient data-driven standards work

(see issue 14)

The goal of the HTML Working Group is to continue the development of the HTML language. As such, it will continue to maintain and produce incremental revisions to the HTML specification and its extensions, and drive interoperability of implementations. As in the CSS or WebApps Working Groups, a limited number of individuals from the general public can become (true) invited experts based on expertise.

Each document worked in the Working Group should have two branches: a development one and a stable one. Daily work is expected to happen on the dev branch, including bug fixing. When applicable, changes must be backported to the stable branch. It is encouraged to have different individuals between the dev and the stable branches. The goal of the development branch is to encourage convergence of the implementations towards interoperability as well as introduce new function. The goal of the stable branch is to document expected interoperability.

The amount of resources from the W3C Team will vary depending on the need for innovation and interoperability around HTML.


The HTML Working Group is expected to demonstrate interoperability to move stable branches towards W3C Recommendation status. It is recommended to have a common set of exit criteria for the modules. This effort must be coordinated with testing through the Test the Web Forward efforts.

For features that are well known to be widely implemented and deployed, and where implementations are believed to match the specification, the Working Group will make judgment call to move to W3C Recommendation status based on sufficient testing; 100% pass rate will not necessarily be required. In any case where the judgment is debatable, it will be a Working Group decision whether sufficient interoperability has been achieved.


Althougth we demonstrate interoperability while moving to W3C Recommendation status, the Web Platform changes and we need to continually update the specifications to maintain actual interoperability in the field. The HTML Working Group's goal is to monitor interoperability of the implementations to achieve actual interoperability. As such, it is expected to maintain HTML and its extensions, and the Chairs and Team need to ensure that bugs get property triaged, prioritized, and addressed. The triage and prioritarization should be based on real-world usage.



A GPL-compatible with attribution License, such as the W3C Software and Document license, will be used for the HTML specification and the HTML extensions in the Community Group and the Working Group.


The Web Platform Incubator Community Group and the HTML Working Group are expected to have well-coordinated good leaders, well accepted and recognized by the community. The leaders should be selected to be magnets for the community - that HTML@W3C has become an effective place to get work done. The leaders must ensure efficient progress and prevent discussion derailments. Due process, broad consensus, transparency, balance, and openness are the principles guiding the Community and Working Groups. Note that CG and WG leaders have different qualities:

Contributions and Communications

The Web Platform Incubator Community Group and the HTML Working Group conduct their work primarily through github repositories, for contributions and communications. Discourse may be used for broad discussions with the community. There will be one github repository per document. Similar to open-source software development, peer production is encouraged: changes will be executed through Pull Requests, where each pull request gets preferably reviewed before being merged.
See also Web Platform Specs. The Community and Working Groups will use common communication means, to facilitate participation and continuity (e.g. similar github repositories or list).

Regular activity summaries around the github repositories must be provided.


All Working Group participants are also encouraged to be participants in the Web Platform Incubator Community Group. A major objective of this new plan is to encourage participation by those who can best drive innovation and interoperability for the web platform. When an idea gets transitioned into the Working Group, care should be taken in ensuring continuity in participation.

Team Participation

W3C Team will participate in both Groups, integrate data sources for interoperability and prioritarization purposes, and help the leadership with transitioning ideas.

Browser engines meeting

(see issue 10)

Note: This section is somewhat orthogonal to the proposal and will probably be removed in the future.

To ensure proper focus and prioritization, the W3C Team will ensure proper sychronization of vendor interests. As such, the W3C Team will hold quarterly meetings with those with authority over what gets committed to a consumer browser engine codebase. The scheduling, agenda, and minutes of those meetings will be made publicly available.

Data-Driven Group

There are several existing data metrics to help prioritize interoperability issues:

Technical Directions

While the technical direction for HTML will continue to evolve, here are some of the topics which we already know to be of interest for, and should be considered by the Web Platform ICG based on data-driven metrics to identify common patterns:

Markup for mobile UI widgets
There may be a set of elements that could usefully be added to HTML for (semantic) application components. One widget may be to provide a way for the user to indicate his geolocation to the application, without having to go through extra validation.
Stylable form controls
HTML5 Forms have the serious drawbacks of not being stylable, impeding their adoption. In order to define style, those forms would need to have structure, such as through Web Components
Responsive-but-performant design
The Responsive Images Community Group made progress in the area of images but more needs to be done.
Media APIs
New Media APIs are needed, and some coherence could usefully be brought amongst all the people extending HTMLMediaElement.
The 2DContext is an area of continued interest and given its specific, focused work.

The HTML Working Group will continue the following efforts:

The existing joint HTML-WebApps TF is already well under way.
Media APIs
There is ongoing work around media streams and encrypted media extensions.
Much useful work is still needed in order for the Web platform to be accessible, such as panels, or the Accessibility API mappins.

@plhw3org, contribute: w3c/charter-html