Web Platform Working Group Charter
The mission of the
Web Platform Working Group is to continue
development of the HTML language and provide
specifications that enable improved
client-side application development on the Web, including application programming interfaces
(APIs) for client-side development and
markup vocabularies for describing and controlling client-side application behavior.
This proposed charter is available
Feel free to raise issues.
||15 June 2017
||30 September 2018
||Proceedings are Public
||Adrian Bateman, Charles McCathie Nevile, Léonie Watson
(FTE %: 100)
|Yves Lafon, Xiaoqian Wu
|Usual Meeting Schedule
||Teleconferences: There are generally not regular teleconferences.
Topic-specific calls may be held up to once per week if needed.
Face-to-face: we will meet during the W3C's annual Technical Plenary week; up to 2
other F2F meetings may be scheduled for the
full group; Up to 4 meetings per year may be scheduled for subgroups working on
IRC: active participants, particularly editors, regularly use the group's IRC
The Web Platform Working Group was the result of merging the Web Applications Working
Group and the HTML Working Group in 2015,
with some deliverables moved to other groups. The work boundaries between the two Working
Groups had narrowed over the years,
given that it is difficult to introduce new HTML elements and attributes without looking
at their implications at the API level.
The initial experiment in merging the group for 12 months was followed by an 18 month
extension, removing some deliverables
considered unlikely to progress within that period, and including others with a specific
requirement that there is a prospect of
success before work will continue within the Working Group.
This proposed charter update adds some new deliverables, removes some to split the work
into a separate group and extends the
group by a further 6 months.
The group will:
- Continue the development of the HTML language, and associated APIs.
- Ensure that developers can use Web technologies to build client-side applications that
rely on Web engines as application
- Provide generic and consistent interoperability and integration among all target
formats, such as HTML, CSS, and SVG.
- Continue to define normative requirements for applications that process HTML
resources, including browsers and other
interactive user agents, authoring tools, content management tools, and conformance
- Ensure Web applications can work across a wide range of devices and among a broad
diversity of users, in particular addressing
issues of accessibility, device independence, internationalization, privacy, and
The group will be considered successful if it produces
- Stable versions of specifications addressing the work items listed in the Milestones section,
with normative conformance requirements for implementation,
- A test suite for each deliverable, sufficiently broad to demonstrate
- and Implementation reports for deliverables showing adoption,
resulting in the ready availability of multiple, independent, interoperable
implementations of each deliverable, including in
browsers, authoring and validation tools, and usage on the Web.
If participants from fewer than three distinct browser-engine projects are
participating in the group, its charter should be
re-examined by the W3C.
The working group will work on the following W3C specifications:
- Database and Offline
- A set of objects and interfaces for client-side database functionality. For more
details, see the Web Platform WG Database
API page. The following Database APIs are deliverables under this charter:
- Indexed Database API (2nd
Edition) - Editors' Copy
- An API for a database of records holding simple values and hierarchical
- Document Object Model (DOM)
- A set of specifications defining objects and interfaces for interaction with a
document's tree model. These deliverables
- An update for DOM4
- DOM defines a platform-neutral model for events and node trees.
- DOM Parsing and
- Parsing markup into a DOM, and serialize for export, an HTML or XML fragment or
- A specification that gives authors information about the visibility of particular
- UI Events - Editors' Copy
- Events typically implemented by interactive user agents for user interaction such
as mouse and keyboard input.
KeyboardEvent code Values - Editors' Copy
- Identifying the physical key being pressed by the user.
KeyboardEvent key Values - Editors'
- Information about the character generated by key events.
- Editing APIs
- Clipboard API and
events - Editors' Copy
- Expose common clipboard operations such as cut, copy and paste to Web
API - Editors' Copy
- APIs for selection, which allows users and authors to select a portion of a
document or specify a point of interest for
copy, paste, and other editing operations.
- Static Range
- A utility API defining a simple range, for optimized performance
- Input Events - Editors' Copy
- A specification defining additions to events for text and related input to allow
for the monitoring and manipulation of
default browser behavior in the context of text editor applications and other
applications that deal with text input and
- contentEditable - Editors' Copy
- A specification defining new values for the
- Defines the behavior of the editing commands that can be executed with
API - Editors' Copy
- An API that enables Web applications to select file objects and access their data.
This replaces the File Upload
- Gamepad - Editors' Copy
- APIs that allow Web applications to directly act on gamepad data.
- Specifications to define the HTML language, HTML-specific APIs for interacting with
in-memory representations of resources
that use the HTML language, and to define normative requirements for browsers and other
user agents which process HTML
- The core language of the World Wide Web: the Hypertext Markup Language (HTML). The
HTML specification should be
progressively modularized into separate documents or extension
specifications. Note that many other Working Groups define extensions to HTML.
These should be referenced from the HTML Extension
- HTML Accessibility API
Mappings 1.0 - Editors'
- How to map HTML elements and attributes to platform accessibility APIs.
- ARIA in HTML
- Describing the use of ARIA attributes on HTML elements.
- Widely-used attributes on HTML elements to provide metadata, e.g. as Schema.org or
- Manifest for Web
applications - Editors' Copy
- A JSON-based manifest, to provide metadata about a web application.
- Specifications that allow network communications:
- Web Sockets API - Editors' Copy
- An API to use the Web Sockets protocol for two-way communication with a remote
- Pointer Lock (2nd
Edition) - Editors' Copy
- Defines an API that provides scripted access to raw mouse movement data while locking
the target of mouse events to a single
element and removing the cursor from view.
- Push API - Editors' Copy
- An API that provides web applications scripted access to server-sent
Orientation API - Editors'
- An API to enable reading or locking view orientation, and notification of view
orientation state changes.
- Web Components
- Adding custom elements to a document, with well-defined behavior and rendering.
- Custom Elements
- Editors' Copy
- Define and use new types of DOM elements in a document.
- Shadow DOM
- Editors' Copy
- Functional boundaries between DOM trees and how these trees interact with each
other within a document, enabling better
functional encapsulation within the DOM.
- Web Interface Definition
Language (Web IDL)
- Language bindings and types for Web interface descriptions.
Workers - Editors' Copy
- An API that allows Web application authors to spawn background workers running scripts
in parallel to their main page,
allowing for thread-like operation with message-passing as the coordination
The following documents have been identified as potential Recommendation Track
deliverables, if there is consensus in the Working Group that they are
ready to become Recommendation-track.
- HTML Canvas 2D Context
- An API for the 2D Context of the HTML canvas element.
- Input Method (IME) API
- An API that provides access to a (native) input method editor.
- A local sandboxed file system API exposed only to Web Applications.
- Packaging on
- Defines an approach for creating packages of files for use on the web.
- Quota Management API
- An API for managing the amount of storage space (short- or long-term) available for an
application to use e.g. in localStorage.
- HTML Imports
- A way to include and reuse HTML documents in another HTML document.
Note: The list of specifications above were Recommendation Track documents in
the previous charter. They are not statements about incubation success,
but examples of the incubation process applied to the list of deliverables in the
Each specification should detail any known security implications for implementers, Web
authors, and end users.
The Web Platform WG will actively seek security, privacy, internationalization,
accessibility and architectural review on all its specifications.
If a specification reaches Recommendation status the working group may work on, and
deliver an updated version of the specification under this charter.
Specifications may be moved to Recommendation and a subsequent version begun
to facilitate the progress of other work which depends on a stable reference.
The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or a similar incubation phase.
If the Working Group decides to add new Recommendation-track deliverables
then it will recharter with changes to change its deliverables.
For current information on the list of deliverables and their status see the Web Platform
WG Publication Status page.
The working group will maintain errata and publish revisions, as necessary, for the
following W3C Recommendations:
Other non-normative documents may be created such as:
- Test suites for each specification
- Primers for each specification
- Requirements documents for new specifications
- Non-normative schemas for language formats
- Non-normative group notes
A comprehensive test suite for all features of a specification is necessary to ensure
the specification's robustness,
consistency, and implementability, and to promote interoperability between User Agents.
Therefore, each specification must have
a companion test suite, which should be completed before transition to Candidate
Recommendation, and must be completed, with an
implementation report, before transition from Candidate Recommendation to Proposed
Recommendation. Additional tests may be added
to the test suite at any stage of the Recommendation track, and the maintenance of a
implementation report is encouraged.
The group's Publication Status
document provides current data about
all of the group's specifications. Although the group expects all of its active
deliverables to progress during this charter
period, the charter does not include detailed milestone data for each
specification because such data is speculative and
easily becomes out of date. The Working Group does expect the following to occur:
- HTML 5.2 Recommendation in Q4 2017
- HTML 5.3 First Public Working Draft in Q3 2017
- IndexedDB version 2 Candidate Recommendation in Q3 2017
- IndexedDB version 3 First Public Working Draft in Q3 2017
- Web Sockets: Recommendation expected in 2017
- DOM Parsing and Serialization: Recommendation expected in 2017
- DOM 4.1 Recommendation expected in 2017
- Microdata: Recommendation expected in late 2017
Dependencies and Liaisons
HTML depends on, and is depended on by, many specifications. Many specifications in many
Working Groups depend on WebIDL. Web
Sockets depends on work in the IETF's HyBi Working Group.
This working group depends on review of aspects such as accessibility, architectural
security, and privacy in its deliverables.
The Web Platform Working Group will keep contact with and where applicable request review
from at least the following:
- Accessible Platform Architectures Working
- This Group ensures W3C specifications provide support for accessibility to people with
- Accessible Rich Internet Applications Working
- WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web
content and Web applications more
accessible to people with disabilities and is integrated into HTML to improve the
accessibility and interoperability of web
content and applications.
- Browser Testing and
Tools Working Group
- This group's Web Driver specification is of interest to the Web Platform WG.
- Cascading Style Sheets Working
- To collaborate on CSS-related aspects of specifications such as Shadow DOM.
- Device and Sensors Working
- To coordinate regarding APIs for device services.
- Digital Publishing Working Group
- This group has a core interest in the manifest specification,
and its scope includes a packaging deliverable.
- Internationalization Core Working
- This group provides advice or review to ensure that specifications meet the needs of
an international Web.
- Pointer Events Working Group
- This group creates DOM extension specifications and is interested in DOM Level 3
Events and UI Events.
- Privacy Interest Group (PING)
- The Web Platform WG will request review of specifications from this group.
- SVG (Scalable Vector Graphics)
- To help ensure SVG requirements for the Web Platform WG's deliverables are met. The
HTML markup language supports embedding
SVG content and provides support for the Canvas 2D Context API.
- Technical Architecture Group
- The Web Platform WG will ask the Technical Architecture Group to review
- Media and Entertainment Interest Group
- This Group may review existing work, as well as the relationship between services on
the Web and media services, and identify
requirements and potential solutions to ensure that the Web will function well with
- Web Application Security Working
- This Group develops security and policy mechanisms to improve the security of Web
Applications, and enable secure cross-origin
- Web Performance Working Group
- Many of their specifications extend Web Platform WG deliverables.
- Web Platform Incubator Community
- This group provides a venue for proposing, incubating and discussing new web platform
features to prepare them for
standardisation, often in the Web Platform WG.
- Web Real-Time Communications Working
- This group creates API specifications for Real-Time Communications in Web
- Web Security Interest Group
- The Web Platform WG will request review of specifications from this group.
The Working Group may also collaborate with:
- Consumer Technology Association (CTA) WAVE project
- The CTA WAVE project aims to improve the way internet delivered video is consumed and distributed, referencing the HTML5 standard in the process. As the Web Platform Working Group develops the HTML specification, it should liaise with the CTA WAVE project.
- ECMA Technical Committee 39 (TC39)
- This is the group responsible for ECMAScript standardization, and related ECMAScript
features like E4X. As the Web
Platform Working Group will be developing ECMAScript APIs, it should collaborate
- Internet Engineering
- The IETF is responsible for defining robust and secure protocols for Internet
functionality. A close relationship with the
IETF HTTP work is crucial to ensuring the good design, deployment, and success of
protocol-based APIs such as CORS and Web
Sockets. This Working Group will rely upon review and parallel progress of associated
specifications, and will keep pace with
the IETF's HTTPbis
group' work, conditional upon steady
progress. The working group may also liaise with the IETFs security work, either
directly or through its liaison with the
W3C's Web Application Security Working Group.
- The Web Platform WG and the WHAT WG both produce versions of the HTML and DOM
The Web Platform WG works on these specifications for many reasons, including:
Based on these considerations, the Web Platform WG exercises independent editorial
control over these specifications. The WG nonetheless endeavours to minimize
differences between the WHAT WG and W3C versions that affect
- The specifications are protected under the W3C Patent Policy,
ensuring that HTML and DOM remain royalty free for use by implementors and
- The specifications are developed with contributions from a broad range of
including implementors and authors,
as well as specialists in accessibility, internationalisation, privacy, and
- The specifications are produced by a globally recognised standards organization,
with a governance model that is designed to find consensus
amongst the many diverse constituents of the web platform.
To be successful, the Web Platform Working Group is expected to have 10 or more active
participants for its duration, and to have
the participation of industry leaders in fields relevant to the specifications it
If participants from fewer than three distinct browser-engine projects are participating
in the group, its charter should be
re-examined by the W3C.
The Chairs, specification Editors and test Facilitators are expected to contribute one to
two days per week towards the Working
Group. There is no minimum requirement for other Participants.
The group's working mode is
generally not to hold
plenary teleconferences, but to meet face to face at the TPAC for both specific topics and
"in plenary". It holds spec- or
topic-specific meetings from time to time, and certain specifications are developed with
regular teleconferences. Note the Decision
Policy below with regards to meetings.
The Working Group conducts its work primarily through GitHub repositories.
The Group uses mailing lists. Subscription to these lists is open to the public, subject
to W3C norms of behavior.
Up-to-date information about the group is available from the Web Platform Working
Group home page.
As required by the W3C Process Document (section 3.3),
this group will seek to make decisions when there is consensus and with due process. The
expectation is that, an editor or other
participant makes an initial proposal, which is refined in discussion with members of the
group and other reviewers, and consensus
emerges with little formal voting being required.
If a decision is necessary for timely progress, but consensus is not achieved after
careful consideration of the range of views
presented, the Chairs may put a question out for voting within the group to allow for
asynchronous participation, using the
mechanism noted in the group's Work Mode
and record a decision, along with any objections. The matter should then be considered
resolved unless and until new information
Any resolution taken in a face-to-face meeting or teleconference is to be
considered provisional until 10 (ten) working
days after the publication of the resolutions in meeting minutes. When the meeting minutes are sent to the appropriate working group mailing list as described
in the Work
Mode document, the presence of formal resolutions will be clearly indicated in the email. If no objections are
raised on the mailing list within that time, the resolution will be considered to have
consensus as a resolution of the Working
This charter is written in accordance with Section 3.4, Votes
of the W3C Process Document and includes no voting procedures beyond what the Process
This Working Group operates under the W3C Patent Policy (5
February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to
issue Recommendations that can be
implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the W3C
Patent Policy Implementation.
About this Charter
This charter for the Web Platform Working Group has been created according to section
5 of the Process Document. In
the event of a conflict between this
document or the provisions of any charter and the W3C Process, the W3C Process shall take
Changes from the previous charter
The major changes from the second Web platform Working Group
Working Group charter include:
- New deliverables:
- Intersection Observers, Static Range
- Moved from deliverable to potential deliverable:
- HTML 2D canvas
- Removed as deliverables:
- Service Workers; Background synchronization (transferred to a new WG)
- High-level user events
- A further 6-month extension of the Working Group
- Updated expected milestones
- Removed note aspiring to modularisation of HTML
- It's often a useful goal, but pragmatic decisions have shown there is no clearly
and the Working Group makes things externally or integrates them on a case-by-case
Yves Lafon, Team Contact
Xiaoqian Wu, Team Contact
Adrian Bateman, Chair
Charles McCathie Nevile, Chair
Léonie Watson, Chair
Copyright© 2017 W3C® (MIT,
Beihang), All Rights Reserved.