Web Applications Working Group Charter

The mission of the Web Applications Working Group (WebApps WG) is to produce specifications that facilitate the development of client-side web applications.

Join the WebApps Working Group

Start date The date when the charter is approved.
End date 2 years after the charter approved.
Chairs Léonie Watson (TetraLogical), Marcos Cáceres (Apple Inc., 0.2 FTE)
Team Contacts Xiaoqian Wu (0.1 FTE)
Meeting Schedule Teleconferences: topic-specific calls will be held when needed.
Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of participants.

Scope

The scope of the WebApps Working Group is:

The working group also maintains a specification for mapping HTML elements and attributes to platform accessibility APIs, and a separate specification that defines author conformance requirements for setting ARIA attributes. The Working Group does not expect to add any other specifications relating to this matter.

Specifications produced by the WebApps Working Group enable developers to create web applications that work across a wide range of platforms and devices, and for a broad diversity of users, by addressing matters of accessibility, device independence, internationalization, privacy, and security.

Success Criteria

In order to advance to Candidate Recommendation and to add features after reaching Candidate Recommendation, each feature is expected to be supported by at least two implementations, which may be judged by factors including existing implementations, expressions of interest, and lack of opposition.

In order to advance to Proposed Recommendation, each specification must have at least two independent implementations in wide use.

Each specification should contain separate sections detailing all known security and privacy implications for implementers, Web authors, and end users.

There should be testing plans for each specification, starting from the earliest drafts.

Each specification must have an accompanying test suite, which is ideally developed in parallel to the specification. The test suite will be used to produce an implementation report before the specification transitions to Proposed Recommendation.

Where there are implications for user experience, each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.

Deliverables

More information about WebApps Working Group specifications can be found in the GitHub repository.

Normative Specifications

The WebApps Working Group will deliver the following normative specifications.

Specification Description
File API An API for representing file objects in web applications, as well as programmatically selecting them and accessing their data.
Gamepad API

Level 1 of the API that represents gamepad devices, and enables web applications to act upon gamepad data.

Level 2 aims to support the capabilities of next generation gamepads.

Image resource This document defines the concept of an "image resource" and a corresponding WebIDL ImageResource dictionary. Web APIs can use the ImageResource dictionary to represent an image resource in contexts where an HTMLImageElement is not suitable or available (e.g., in a Worker).
Indexed Database API An API for a database of records holding simple values and hierarchical objects. The third edition adds new capabilities and improves developer ergonomics by using promises.
Intersection Observer An API that can be used to understand the visibility and position of DOM elements ("targets") relative to a containing element or to the top-level viewport ("root").
Pointer Lock 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 An API for sending push messages to a web application, via a push service.
Screen Orientation API An API for reading screen orientation, being informed of screen orientation changes, and locking screen orientation to a specific state.
Web App Manifest A JSON-based manifest file that provides developers with a centralized place to put metadata associated with a web application.
Web Share API An API for sharing text, links and other content to an arbitrary destination of the user's choice.
ARIA in HTML Defines the web developer rules (author conformance requirements) for ARIA attributes on HTML elements.
UI Events UI Events that extend the DOM Event objects defined in the DOM specification.
UI Events KeyboardEvent code values The values for the KeyboardEvent.code attribute, which is defined as part of the UI Events Specification.
UI Events KeyboardEvent key Values The values for the key attribute defined in the UI Events specification.
Web Locks API This document defines a web platform API that allows script to asynchronously acquire a lock over a resource, hold it while work is performed, then release it. While held, no other script in the origin can acquire a lock over the same resource. This allows contexts (windows, workers) within a web application to coordinate the usage of resources.

Depending on the Consensus of the Working Group members, the Group may bring the following WHATWG Review Drafts from W3C Candidate Recommendation to Proposed Recommendation, in accordance with the WHATWG-W3C Memorandum of Understanding and 2021 Relationship Update.:

Specification Description
Web IDL This document defines an interface definition language, Web IDL, that can be used to describe interfaces that are intended to be implemented in web browsers. Web IDL is an IDL variant with a number of features that allow the behavior of common script objects in the web platform to be specified more readily. How interfaces described with Web IDL correspond to constructs within ECMAScript execution environments is also detailed in this document. It is expected that this document acts as a guide to implementors of already-published specifications, and that newly published specifications reference this document to ensure conforming implementations of interfaces are interoperable.

WICG specifications

Depending on the WICG progress, including interest from multiple implementers, the Group may also produce W3C Recommendations for the following documents:

Specification Description
Cookie Store An asynchronous Javascript cookies API for documents and workers.
Web Share Target An API that allows websites to declare themselves as web share targets, which can receive shared content from either the Web Share API, or system events (e.g., shares from native apps).
Badging An API allowing web applications to set an application-wide badge, shown in an operating-system-specific place associated with the application (such as the shelf or home screen), for the purpose of notifying the user when the state of the application has changed (e.g., when new messages have arrived), without showing a more heavyweight notification.
Contact Picker API An API to give one-off access to a user’s contact information with full control over the shared data. It will be a joint deliverable with the Devices and Sensors Working Group.
Haptics An API allowing web applications to interface with haptic actuators, such as vibration motors found on gamepad controllers, and potentially other devices that provide haptic feedback.
User-Agent Client Hints This document defines a set of Client Hints that aim to provide developers with the ability to perform agent-based content negotiation when necessary, while avoiding the historical baggage and passive fingerprinting surface exposed by the venerable User-Agent HTTP header.

Other Deliverables

Other non-normative documents may be created such as, use case and requirements documents, implementation reports, and Best Practices documents, to support web developers when designing applications.

Timeline

All specifications produced by the WebApps Working Group are expected to progress during this charter period. The charter does not include a detailed timeline for each specification because such information is speculative and easily becomes inaccurate. However, a rough estimation of completion is available in the detailed list of Deliverables when possible.

The Working Group home page will link to a more comprehensive page with detailed status and estimated completion time for each specification.

Note that the WICG Specifications, if adopted, have an estimated time of completion of 2 years.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.

For all specifications, technical coordination with the following Groups will be made, per the W3C Process Document:

Accessible Platform Architectures (APA) Working Group
For accessibility horizontal review, and to collaborate on accessibility related topics.
Internationalization Working Group
For internationalization horizontal review, and to collaborate on internationalization related topics.
Privacy Interest Group
For privacy horizontal review, and to collaborate on privacy related topics.
Technical Architecture Group (TAG)
For architectural horizontal review, and to collaborate on architecture related topics.

The WebApps Group will also seek review from the Accessible Rich Internet Applications (ARIA) Working Group to coordinate on the ARIA attributes on HTML elements, and their mappings to platform accessibility APIs.

W3C Groups

The work of the WebApps Working Group touches on the work of many other W3C Working and Interest Groups. Where appropriate, the WebApps Working Group will coordinate with the relevant Working or Interest Groups, per the W3C Process.

External Organizations

The WebApps Working Group may also coordinate with the following organizations:

ECMA TC39
For co-ordination on topics relating to JavaScript.
Internet Engineering Task Force (IETF)
For co-ordination on topics relating to internet protocols.
Web Hypertext Application Technology Working Group (WHATWG)
For co-ordination on topics relating to the web platform.

Participation

To be successful, the WebApps Working Group is expected to have 10 or more active participants for its duration, including representatives from at least three key implementors. It is also expected to have active Editors and Test Leads for each specification.

Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the WebApps Working Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes technical contributions from non-Members, to be considered upon their agreement to the terms of the W3C Patent Policy.

Working mode

This group primarily conducts its technical work on GitHub. The public is invited to review, discuss and contribute to this work.

The Chairs and Editors will assess support from web platform implementers or web application or framework developers, to assure that substantial changes are supported by more than a single member before they are adopted.

Additionally, support from two or more web platform implementers is required before a substantive change can be made to a specification. This is enforced by a pull request template on GitHub, which Editors must fill out as a public record before a substantive contribution can be merged. The template will require implementers to give public support for a change/fix/feature and, where possible, provide a link to a public bug tracker for an implementation.

Communication

Technical discussions for the WebApps Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and contributed to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on public repositories, and may permit direct public contribution requests.

Meetings are not open to public participation, however non-members may request observer status at meetings by contacting the WebApps Working Group Chairs.

Information about the WebApps Working Group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the WebApps Working Group home page.

The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). 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 and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional.

A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue.

If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the WebApps Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 3.4, Votes) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). 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.

Licensing

The WebApps Working Group will use the W3C Software and Document license for all its deliverables. WebIDL will follow the terms of the WHATWG-W3C Memorandum of Understanding and 2021 Relationship Update.

About this Charter

This charter has been created according to section 5.2 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.

Charter History

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):

Charter Period Start Date End Date Changes
Initial Charter 14 May 2019 31 May 2021 none
Rechartered 15 December 2020 31 May 2021 New Patent Policy
Rechartered 1 June 2021 31 May 2023
  • Stopped Working on the HTML Accessibility API Mappings (AAM) spec;
  • Remove Clipboard API and Events, ContentEditable, Selection API, and Input Events from the Deliverables.
  • Add WebIDL to the charter as a possible Deliverable.

Note: Starting from 16 July 2020, the team contacts of the WebApps Working Group reduced from Yves Lafon (0.3 FTE), Xiaoqian Wu (0.2 FTE) to Xiaoqian Wu (0.1 FTE). Starting from 5 November 2020, Marcos Cáceres re-appointed as co-chair after affiliation change. We made non-substantive modifications to this charter to reflect these changes.

History of this WG

The WebApps Working Group was a predecessor to the Web Platform Working Group (which remains active to work on specifications that are pertinent to the discussions relating to a collaboration agreement between the W3C and the WHATWG). The remaining specifications have been transferred from the Web Platform Working Group to the WebApps Working Group, so that progress can continue to be made on those specifications while the W3C and WHATWG negotiations are ongoing.

In addition, specifications that have been successfully incubated in the Web Platform Incubator Community Group (WICG) have been transferred to the WebApps Working Group.

Detailed list of Deliverables