Web Platform Working Group Charter
The mission of the Web
Platform Working Group is to continue the development of the HTML language, providing 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.
Start date | October 9, 2015 |
End date |
30 September 2016 |
Charter extension |
The charter extension history is documented in "About this charter" |
Confidentiality |
Proceedings are Public |
Chairs |
Adrian Bateman, Art Barstow, Charles McCathie Nevile, Léonie Watson |
Team Contacts
(FTE %: 1.55) |
Yves Lafon, Xiaoqian Wu, TBD |
Usual Meeting Schedule |
Teleconferences: topic-specific calls
may be held up to once per week
Face-to-face: we will meet during the W3C's annual Technical
Plenary week; other F2F meetings may be scheduled (up to 2 per year for the full
group, and/or additional meetings of subgroups working on specific
topics.)
IRC: active participants, particularly editors, regularly use the
group's IRC channel(s) |
Background
This Working Group is the result of merging the Web Applications Working Group and the HTML Working Group, not including the work of the HTML Media Task Force.
The work boundaries between the two Working Groups have narrowed over the years, given that it is difficult nowadays to introduce new HTML elements and attributes without looking at their implications at the API level. While there is desire to reorganize the work in terms of functionalities rather than technical solution, resulting in several Working Groups, this Working Group is an interim group while discussion is ongoing regarding the proper modularization of HTML and its APIs, and it enables the ongoing specifications to continue to move forward over the next 12 months.
Scope
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 runtime environments.
- 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 (but not limited to) browsers and other interactive user agents, as well as authoring tools, markup generators, and conformance checkers.
- Ensure universal access to Web applications across a wide range of devices and among a diversity of users, by addressing issues of accessibility, device independence, internationalization, and mobility.
- Ensure proper privacy and security reviews of its deliverables.
The Web Platform Working Group should develop modular specifications to the greatest extent possible for the development of the HTML language, allowing extension specifications to define new elements, new attributes, new values for attributes that accept defined sets of keywords, and new APIs.
Success Criteria
The group will be considered successful if its deliverables are widely used. In particular:
- Production of stable documents addressing the work items
listed in the Milestones section.
- A test suite for each deliverable with conformance criteria that provides evidence to support the position that there is good (though perhaps not perfect) interoperability.
- Availability of authoring tools and validation tools.
- User-community and industry adoption of the group deliverables.
- Availability of multiple, independent, interoperable browser
implementations of each deliverable. Remaining differences in implementations should have little impact on usage on the Web.
- Specifications include normative conformance
requirements for browser implementations.
- Implementation reports that summarize the implementation status against
the relevant test suite.
If participants from fewer than three distinct browser-engine
projects are participating in the group, its charter should be
re-examined by the W3C.
Deliverables
Recommendation-Track Deliverables
The working group will work on the following W3C specifications:
- Clipboard
API and events
- A specification to expose common clipboard operations such as cut,
copy and paste to Web Applications.
- Database and Offline Application APIs
- 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)
- An API for a database of records holding simple values and hierarchical objects
- Quota Management API
- An API for managing the amount of storage space (short- or
long-term) available.
- Service Workers
- A new feature for the Web Platform that lets a
script persistently cache resources and handle all resource requests
for an application -- even when the network isn't available.
- Web Storage (2nd Edition)
- An API for persistent data storage of key-value pair data in Web clients.
- Document Object Model (DOM)
- A set of specifications defining objects and interfaces for
interaction with a document's tree model. These deliverables
include:
- DOM4
- DOM defines a platform-neutral model for events and node trees.
- DOM Parsing and Serialization
- A specification describing how to parse markup into a DOM, and
serialize for export, an HTML or XML fragment or document. This
was initially developed in the WHAT-WG.
- High Level User Events
- A specification to enable authors to support user interaction in Web applications easily
without requiring specific hardware, platform, or input methodologies to be in use.
- UI Events
- A specification defining UI Events, those typically implemented by visual user agents for
handling user interaction such as mouse and keyboard input.
- UI Events KeyboardEvent code Values
- A specification describing information that can use used identify the physical key
being pressed by the user.
- UI Events KeyboardEvent key Values
- A specification describing information about the character generated by the key event.
- Selection API
- 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.
- File
API
- An API that enables Web applications to select file objects
and access their data. This replaces the File Upload
specification.
- Gamepad
- APIs that allow Web applications to directly act on gamepad data.
- HTML
-
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 resources.
- HTML
- A specification defining the core language of the World Wide Web: the Hypertext Markup Language (HTML). The updated HTML specification should be modularized into separate documents. When extensions to the HTML specification are needed, separate extension specifications can be written. Note that the maintenance of the HTMLMediaElement related sections of HTML 5.0 (e.g. sections 4.7.6 to 4.7.10) is expected to happen within the proposed Timed Media Working Group.
- HTML Canvas 2D Context
- An API for the 2D Context of the HTML canvas element.
- HTML Accessibility API Mappings 1.0
- A specification defining how user agents map HTML elements and attributes to platform APIs. This work is jointly done with the Accessible Rich Internet Applications Working Group.
- ARIA in HTML
- A specification defining the web developer rules for the use of ARIA attributes on HTML elements.
- Manifest for Web applications
- A JSON-based manifest, which provides developers with a
centralized place to put metadata about a web application.
- Network
-
Specifications that allow network communications:
- Web
Sockets API
- An API that enables Web pages to use the Web Sockets protocol for
two-way communication with a remote host.
- HTTP client interactions
-
- XHR Level 1
- An API that provides scripted client functionality for transferring data between a client and a server.
- Fetching resources
- The Group MAY define the mechanisms to fetch resources using the HTTP protocol and its extensions.
- Streams API
- An API for representing a stream of data in web applications.
- Pointer Lock
- Defines APIs that provide 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
- An API that provides web applications scripted access to server-sent notifications.
- Screen Orientation API
- A view orientation and locking API, e.g. to enable reading the
view's orientation state, locking view orientation, notification of
view orientation state changes.
- URL
- The Group MAY provide a specification defining the syntax, process and error handling
for resolving URL, along with its API.
- Web Components
- Specifications that define mechanisms for adding custom
elements to a document which allows them to have well-defined behavior
and rendering.
- Custom Elements
- Methods for enabling the author to define and use new
types of DOM elements in a document.
- Shadow DOM
- A method of establishing and maintaining functional
boundaries between DOM trees and how these trees interact with
each other within a document, thus enabling better functional
encapsulation within the DOM.
- Web Interface
Definition Language (Web IDL)
- Language bindings and types for Web interface descriptions.
- Web
Workers
- 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
mechanism.
The following deliverables may be picked up once they have gone through an incubation phase:
- Editing APIs
-
- Input Events
- A specification defining events for text and related input, and provides relevant contextual information for each event.
- contentEditable
- A specification defining new values for the
contentEditable
attribute.
- execCommand
- This document defines the behavior of the editing commands that can be executed with execCommand.
- Input
Method (IME) API
- The Group MAY define an API that provides access to a (native) input method editor.
- FileSystem
API
- A local sandboxed file system API exposed only to Web Applications.
- Packaging on the Web
- Defines an approach for creating packages of files for use on the web.
- FindText API
- APIs for linking to a document selection, even when the document
has changed. This is a joint deliverable with the Web
Annotation WG.
- HTML Imports
- A way to include and reuse HTML documents in another
HTML documents.
- Web Background Synchronization
- A specification describing a method that enables Web applications to synchronize data when next online.
Each specification should contain a section detailing any known
security implications for implementers, Web authors, and end users.
The Web Platform WG will actively seek security, privacy,
internationalization and accessibility review on all its
specifications.
After a specification reaches Recommendation status the working group
may begin work on, and deliver an updated version of the specification
under this charter. Specifications may be moved to Recommendation and
a subsequent version begun in order 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 another similar incubation phase. If
the Working Group decides to add new Recommendation-track deliverables
then it will recharter with changes to that new charter limited to
just the changes in deliverables.
For a detailed summary of the current list of deliverables, and an
up-to-date timeline, see the Web Platform WG Publication
Status page.
2.1.1. Specification Maintenance
The working group will maintain errata and new editions, as
necessary, for the following Recommendation-status specifications:
Other Deliverables
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.
Milestones
The group's Specification Status
document provides current data about all of the group's specifications,
including Technical Report publication plans and testing status.
Although the group expects all of its specifications 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. However, for each of these specifications,
some milestone predictions are provided, but please see the
Specification Status
document for accurate data.
- Web Storage (2nd edition): Recommendation expected in 2016
- Web Workers: Recommendation expected in 2016
- Web Sockets: Recommendation expected in 2016
- DOM Parsing and Serialization: Recommendation expected in 2016
- Web IDL: Recommendation expected in early 2016
Dependencies and Liaisons
Dependencies
A number of specifications depend on the WebIDL specification, which
is therefore a very high priority for the Working Group.
The Web Sockets specification has an effective dependency on the
protocol defined by the IETF's
HyBi Working Group.
Given the large number of deliverables and therefore also
dependencies between this working group and accessibility groups, the
Web Platform team contact(s) will liaise with the team contact for Accessible Platform Architectures and Accessible Rich Internet Applications Working Groups
in order to ensure early identification of specifications with
potential accessibility aspects, and to ensure coordination as needed
during their development.
The specifications of several other groups, such as SVG, depend upon
particular Web Platform Working Group specifications.
Where possible, additional dependencies will be
avoided to prevent the disruption of dependent deliverables.
Liaisons
The Web Platform Working Group expects to maintain contacts with
at least the following groups and Activities within W3C (in
alphabetical order):
- Accessible Platform Architectures Working Group (proposed)
-
This Group ensures W3C specifications provide support for accessibility to people with disabilities.
- Accessible Rich Internet Applications Working Group (proposed)
-
This Group develops technologies that enhance accessibility of Web content for people with disabilities, including the Accessible Rich Internet Applications (WAI-ARIA) suite of technologies.
- Browser Testing and Tools
Working Group
- This group's Web Driver specification is of interest to the
Web Platform WG.
- Cascading Style
Sheets Working Group
- To collaborate on CSS related aspects of specifications (such as Shadow DOM).
- Device APIs Working
Group
- To coordinate regarding APIs for device services.
- Digital Publishing Interest Group
- This group may provide advice or review to ensure that Web Platform WG
deliverables interact correctly in the context of the digital publishing ecosystem.
- Internationalization
Core Working Group
- This group may provide advice or review to ensure that Web Platform WG
deliverables meet the needs of an international Web. In particular
the Working Group will request close review of the IME API.
- Math Working Group
- The HTML markup language includes support for embedding MathML content.
- Pointer Events
Working Group
- This group creates DOM extension specifications and is interested in
Web Platform' DOM Level 3 Events and UI Events specifications.
- Privacy Interest Group (PING)
- The Web Platform WG will request review of specifications and
communicate as necessary with this group.
- SVG (Scalable
Vector Graphics) Working Group
- To monitor the development of the SVG specification as it
complements the Web Platform WG's specifications, and to help ensure SVG
requirements for the Web Platform WG's deliverables are met. The HTML markup language includes support for embedding SVG content and provides support for graphics API, such as the 2D Context API.
- Technical Architecture Group
- The Web Platform WG will ask the Technical Architecture Group to
review some set of its specifications and will help, through a
joint task force, the development of the URL specification
and the Packaging on the Web specification.
- Timed Media Group (proposed)
- The Timed Media Working Group develops timed media capabilities in the Open Web Platform.
- User Agent
Accessibility Guidelines Working Group
- To ensure that Web Platform WG deliverables support accessibility
requirements, particularly with regard to interoperability with
assistive technologies, and inclusion in deliverables of guidance
for implementing Web Platform deliverables in ways that support
accessibility requirements. (This Group is expected to combine into an all-guidelines group in 2016 2Q).
- Web Annotation Working Group
- The Web Platform Working Group has a joint deliverable with this group regarding
robust anchoring.
- Web and Mobile Interest Group
- This group may provide advice or review to ensure that Web Platform WG
deliverables interact correctly in the context of Mobile applications.
- Web and TV Interest Group
- This Group is to provide a forum for Web and TV technical discussions, to review existing work, as well as the relationship between services on the Web and TV services, and to identify requirements and potential solutions to ensure that the Web will function well with TV.
- Web Applications
Security Working Group
- As well as having a joint deliverable (CORS), this group has many
overlapping interests with the Web Platform WG.
- Web Performance Working
Group
- This group focuses on performance of the Web Platform, including
deliverables of the Web Platform WG.
- Web Platform Incubator Community Group
-
This group provides a lightweight venue for proposing, incubating and discussing new web platform features.
- Web Real-Time Communications
Working Group
- This group creates API specifications for Real-Time Communications in Web browsers.
- Web Security Interest Group
- The Web Platform WG will request review of specifications and
communicate as necessary with this group.
The Working Group will consider proposals for future
specifications from Community Groups, encourage open
participation from Community Group members, and keep
coordination with relevant Community Groups, all within the bounds
of the W3C patent policy and available resources.
External Groups
The following is a tentative list of external bodies the Working
Group should collaborate with:
- ECMA
Technical Committee 39 (TC39)
- This is the group responsible for ECMAScript standardization,
and related ECMAScript features like E4X. As the Web Applications
Working Group will be developing ECMAScript APIs, it should
collaborate with TC39.
- Internet
Engineering Task Force
- The IETF is responsible for defining robust and secure protocols
for Internet functionality. A close relationship with the IETF
HTTP group 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 HTTP
and HyBi
groups' work, conditional upon steady progress. The working group
may well also liaise with the IETFs Web Security Working Group,
either directly or through its liaison with the W3C's Web
Applications Security Working Group.
- WHATWG
-
A number of the specifications are derived from specifications originally written at the WHATWG and still being maintained there. For these specifications, the Web Platform Working Group should make an effort to work with the WHATWG editors to avoid differences between the WHATWG and Web Platform WG specifications that would harm interoperability on the Web.
Participation
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 produces.
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 Web Platform Working Group welcomes participation, with
agreement from each participant to the provisions of the W3C Patent
Policy.
Communication
The Working Group operates using a documented working
mode. In general
the group does not hold plenary teleconferences, but does meet face to face at the
TPAC. It may hold more meetings, 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,
for contributions and communications.
Similar to open-source software development,
peer production is encouraged: changes will be executed through Pull Requests, with pull requests reviewed before being merged.
The Chairs must ensure that regular activity summaries around the GitHub repositories activity are provided.
The Group may use mailing lists. Subscription
to these lists is open to the public, subject to W3C norms of
behavior.
Up-to-date information about the group (for example, details about
deliverables, issues, actions, status, and participants) is available from
the Web
Platform Working Group home page.
Decision Policy
As explained in 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 typically, an
editor or other participant makes an initial proposal, which is then
refined in discussion with members of the group and other reviewers,
and consensus emerges with little formal voting being required.
However, 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
documents, and record a
decision, along with any objections. The matter should then be
considered resolved unless and until new information becomes
available.
Any resolution taken in a face-to-face meeting or teleconference is
to be considered provisional until 10 working days after the
publication of the resolutions sent to the appropriate working
group mailing list as described in the Work Mode
documents. 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 Group.
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 Document requires.
Patent Policy
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 precedence.
Yves Lafon, Team Contact
Xiaoqian Wu, Team Contact
TBD, Team Contact
Adrian Bateman, Chair
Art Barstow, Chair
Charles McCathie Nevile, Chair
Léonie Watson, Chair
Copyright©
2015 W3C®
(MIT,
ERCIM,
Keio,
Beihang), All Rights Reserved.