PROPOSED 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

This proposed charter is available on GitHub. Feel free to raise issues.

Charter Status See the group status page and detailed change history.
Start date [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved)
End date [dd monthname yyyy] (Start date + 2 years)
Chairs Léonie Watson (TetraLogical), Marcos Cáceres (Apple, Inc.)
Team Contacts Xiaoqian Wu (0.2 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 the participants, usually no more than 3 per year.

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.

Deliverables

Updated document status is available on the group publication status page.

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.

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 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.
Badging API This specification defines an API that allows installed web applications to set an application badge, which is usually shown alongside the application's icon on the device's home screen or application dock.
Contact Picker API An API to give one-off access to a user’s contact information with full control over the shared data. It's a joint deliverable with the Devices and Sensors Working Group
Screen Wake Lock API This document specifies an API that allows web applications to request a screen wake lock. Under the right conditions, the screen wake lock prevents the system from turning off a device's screen. It's a joint deliverable with the Devices and Sensors Working Group.
DeviceOrientation Event Specification This specification defines several new DOM events that provide information about the physical orientation and motion of a hosting device. It's a joint deliverable with the Devices and Sensors Working Group.
Geolocation API The Geolocation API provides access to geographical location information associated with the hosting device. It's a joint deliverable with the Devices and Sensors Working Group.

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).
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.

Success Criteria

In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or more implementations interoperating with each other. In order to advance to Proposed Recommendation, each normative specification must have an open test suite of every feature defined in the specification.

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.

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

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.

This Working Group expects to follow the TAG Web Platform Design Principles and W3C TAG Ethical Web Principles.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, 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.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

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.

Devices and Sensors Working Group
The Web Application Working Group will coordinate with the Devices and Sensors Working Group regarding the Contact Picker API, the Screen Wake Lock API, the DeviceOrientation Event Specification and the Geolocation API.

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, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the 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 non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.

Working mode

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

Moreover, at least two web platform implementers must support a substantive change before it 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 this 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 written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

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

Most Web Applications Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

This group primarily conducts its technical work on the public mailing list public-webapps@w3.org (archive), and on GitHub issues. The public is invited to review, discuss and contribute to this work.

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 5.2.1, Consensus). 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, GitHub issue 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 by the end of the response period, the resolution will be considered to have consensus as a resolution of the 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.

This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) 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 Web specifications 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 licensing information.

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter has been created according to section 3.4 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
Charter Extension 1 June 2021 30 April 2022 none
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.
Rechartered TBD TBD
  • Add the Screen Wake Lock API, the DeviceOrientation Event Specification, the Geolocation API as joint deliverables with the W3C Devices and Sensors Working Group.

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

The following is the list of non-retired specifications produced by the Web Applications Working Group under the W3C Patent Policy.

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.

Draft state: Working Draft

Expected completion: CR - Q4 2023; REC - Q4 2024

Adopted Draft: Web Locks API, https://www.w3.org/TR/2023/WD-web-locks-20230105/, 5 January 2023

Exclusion Draft: Web Locks API, https://www.w3.org/TR/2023/WD-web-locks-20230105/, 5 January 2023, Exclusion Draft began on 05 Jan 2023; ended on 04 June 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

Contact Picker API

An API to give one-off access to a user’s contact information with full control over the shared data.

Draft state: Working Draft

Expected completion: CR - Q4 2024

Adopted Draft: Contact Picker API9, https://www.w3.org/TR/2023/WD-web-locks-20230105/, 5 January 2023

Exclusion Draft: Contact Picker API, https://www.w3.org/TR/2022/WD-contact-picker-1-20221220/, 20 December 2022, Exclusion Draft began on 20 Dec 2022; ended on 19 May 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

Badging API

This specification defines an API that allows installed web applications to set an application badge, which is usually shown alongside the application's icon on the device's home screen or application dock.

Draft state: Working Draft

Expected completion: CR - Q4 2023; REC - Q4 2024

Adopted Draft: Badging API, https://www.w3.org/TR/2023/WD-badging-20230503/, 03 May 2023

Exclusion Draft: Badging API, https://www.w3.org/TR/2023/WD-badging-20230406/, 06 April 2023, Exclusion Draft began on 06 Apr 2023; ended on 03 September 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

File API

This specification provides an API for representing file objects in web applications, as well as programmatically selecting them and accessing their data. This includes:

  • A FileList interface, which represents an array of individually selected files from the underlying system. The user interface for selection can be invoked via <input type="file">, i.e. when the input element is in the File Upload state [HTML].

  • A Blob interface, which represents immutable raw binary data, and allows access to ranges of bytes within the Blob object as a separate Blob.

  • A File interface, which includes readonly informational attributes about a file such as its name and the date of the last modification (on disk) of the file.

  • A FileReader interface, which provides methods to read a File or a Blob, and an event model to obtain the results of these reads.

  • A URL scheme for use with binary data such as files, so that they can be referenced within web applications.

Additionally, this specification defines objects to be used within threaded web applications for the synchronous reading of files.

§ 10 Requirements and Use Cases covers the motivation behind this specification.

This API is designed to be used in conjunction with other APIs and elements on the web platform, notably: XMLHttpRequest (e.g. with an overloaded send() method for File or Blob arguments), postMessage(), DataTransfer (part of the drag and drop API defined in [HTML]) and Web Workers. Additionally, it should be possible to programmatically obtain a list of files from the input element when it is in the File Upload state [HTML]. These kinds of behaviors are defined in the appropriate affiliated specifications.

Draft state: Working Draft

Expected completion: CR - Q2 2024; REC - Q3 2024

Adopted Draft: File API, https://www.w3.org/TR/2023/WD-FileAPI-20230206/, 6 February 2023

Exclusion Draft: File API, https://www.w3.org/TR/2013/WD-FileAPI-20130912/, 12 September 2013, Exclusion Draft began on 13 Sep 2013; ended on 11 November 2013.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

Gamepad

The Gamepad specification defines a low-level interface that represents gamepad devices.

Draft state: Working Draft

Expected completion: CR - Q1 2024; REC - Q2 2024

Adopted Draft: Gamepad, https://www.w3.org/TR/2023/WD-gamepad-20230413/, 13 April 2023

Exclusion Draft: Gamepad, https://www.w3.org/TR/2012/WD-gamepad-20120529/, 29 May 2012, Exclusion Draft began on 29 May 2012; ended on 26 October 2012.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

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).

Draft state: Working Draft

Expected completion: CR - Q4 2023; REC - Q3 2024

Adopted Draft: Image Resource, https://www.w3.org/TR/2021/WD-image-resource-20210604/, 04 June 2021

Exclusion Draft: Image Resource, https://www.w3.org/TR/2020/WD-image-resource-20200507/, 07 May 2020, Exclusion Draft began on 07 May 2020; ended on 04 October 2020.

Exclusion Draft Charter: https://www.w3.org/2020/12/webapps-wg-charter.html

Indexed Database API 3.0

This document defines APIs for a database of records holding simple values and hierarchical objects. Each record consists of a key and some value. Moreover, the database maintains indexes over records it stores. An application developer directly uses an API to locate records either by their key or by using an index. A query language can be layered on this API. An indexed database can be implemented using a persistent B-tree data structure.

Draft state: Working Draft

Expected completion: CR - Q1 2024; REC - Q3 2024

Adopted Draft: Indexed Database API 3.0, https://www.w3.org/TR/2023/WD-IndexedDB-3-20230613/, 13 June 2023

Exclusion Draft: Indexed Database API 3.0, https://www.w3.org/TR/2021/WD-IndexedDB-3-20210311/, 11 March 2021, Exclusion Draft began on 11 Mar 2021; ended on 08 August 2021.

Exclusion Draft Charter: https://www.w3.org/2020/12/webapps-wg-charter.html

Intersection Observer

This specification describes 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"). The position is delivered asynchronously and is useful for understanding the visibility of elements and implementing pre-loading and deferred loading of DOM content.

Draft state: Working Draft

Expected completion: CR - Q3 2023; REC - Q1 2024

Adopted Draft: Intersection Observer, https://www.w3.org/TR/2022/WD-intersection-observer-20220706/, 6 July 2022

Exclusion Draft: Intersection Observer, https://www.w3.org/TR/2017/WD-intersection-observer-20170914/, 14 September 2017, Exclusion Draft began on 14 Sep 2017; ended on 11 February 2018.

Exclusion Draft Charter: https://www.w3.org/2017/08/webplatform-charter.html

Pointer Lock 2.0

This specification 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. This is an essential input mode for certain classes of applications, especially first person perspective 3D applications and 3D modeling software.

Draft state: Working Draft

Expected completion: CR - Q3 2023; REC - Q3 2024

Adopted Draft: Pointer Lock 2.0, https://www.w3.org/TR/2022/WD-pointerlock-2-20220708/, 08 July 2022

Exclusion Draft: Pointer Lock 2.0, https://www.w3.org/TR/2016/WD-pointerlock-2-20161122/, 22 November 2016, Exclusion Draft began on 22 Nov 2016; ended on 21 April 2017.

Exclusion Draft Charter: https://www.w3.org/2015/10/webplatform-charter.html

Push API

The Push API enables sending of a push message to a web application via a push service. An application server can send a push message at any time, even when a web application or user agent is inactive. The push service ensures reliable and efficient delivery to the user agent. Push messages are delivered to a Service Worker that runs in the origin of the web application, which can use the information in the message to update local state or display a notification to the user.

This specification is designed for use with the web push protocol, which describes how an application server or user agent interacts with a push service.

Draft state: Working Draft

Expected completion: CR - Q3 2023; REC - Q1 2024

Adopted Draft: Push API, https://www.w3.org/TR/2022/WD-push-api-20220630/, 30 June 2022

Exclusion Draft: Push API, https://www.w3.org/TR/2012/WD-push-api-20121018/, 18 October 2012, Exclusion Draft began on 18 Oct 2012; ended on 17 March 2013.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

Screen Orientation

The Screen Orientation specification standardizes the types and angles for a device's screen orientation, and provides a means for locking and unlocking it. The API, defined by this specification, exposes the current type and angle of the device's screen orientation, and dispatches events when it changes. This enables web applications to programmatically adapt the user experience for multiple screen orientations, working alongside CSS. The API also allows for the screen orientation to be locked under certain preconditions. This is particularly useful for applications such as computer games, where users physically rotate the device, but the screen orientation itself should not change.

Draft state: Working Draft

Expected completion: CR - Q3 2023; REC - Q1 2024

Adopted Draft: Screen Orientation, https://www.w3.org/TR/2023/WD-screen-orientation-20230504/, 04 May 2023

Exclusion Draft: The Screen Orientation API, https://www.w3.org/TR/2012/WD-screen-orientation-20120522/, 22 May 2012, Exclusion Draft began on 22 May 2012; ended on 19 October 2012.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

Web Application Manifest

This specification defines a JSON-based file format that provides developers with a centralized place to put metadata associated with a web application. This metadata includes, but is not limited to, the web application's name, links to icons, as well as the preferred URL to open when a user launches the web application. The manifest also allows developers to declare a default screen orientation for their web application, as well as providing the ability to set the display mode for the application (e.g., in fullscreen). Additionally, the manifest allows a developer to "scope" a web application to a URL. This restricts the URLs to which the manifest is applied and provides a means to "deep link" into a web application from other applications.

Using this metadata, user agents can provide developers with means to create user experiences that are more comparable to that of a native application.

Draft state: Working Draft

Expected completion: CR - Q1 2024; REC - Q3 2024

Adopted Draft: Web Application Manifest, https://www.w3.org/TR/2023/WD-appmanifest-20230502/, 02 May 2023

Exclusion Draft: Manifest for web apps and bookmarks, https://www.w3.org/TR/2013/WD-appmanifest-20131217/, 17 December 2013, Exclusion Draft began on 17 Dec 2013; ended on 16 May 2014.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

ARIA in HTML

This specification defines the authoring rules (author conformance requirements) for the use of Accessible Rich Internet Applications (WAI-ARIA) 1.2 and Digital Publishing WAI-ARIA Module 1.0 attributes on [HTML] elements. This specification's primary objective is to define requirements for use with conformance checking tools used by authors (i.e., web developers). These requirements will aid authors in their development of web content, including custom interfaces and widgets, which make use of ARIA to complement or extend the features of the host language [HTML].

Draft state: W3C Recommendation

Expected completion: REC - 2021; Future updates to this Recommendation may incorporate new features.

Adopted Draft: ARIA in HTML, https://www.w3.org/TR/2023/REC-html-aria-20230626/, 26 June 2023

Exclusion Draft: ARIA in HTML, https://www.w3.org/TR/2021/CR-html-aria-20210706/, 06 July 2021, Exclusion Draft began on 06 Jul 2021; ended on 04 September 2021.

Exclusion Draft Charter: https://www.w3.org/2020/12/webapps-wg-charter.html

UI Events

This specification defines UI Events which extend the DOM Event objects defined in [DOM]. UI Events are those typically implemented by visual user agents for handling user interaction such as mouse and keyboard input.

Draft state: Working Draft

Expected completion: CR - Q4 2024; REC - Q4 2025

Adopted Draft: UI Events, https://www.w3.org/TR/2023/WD-uievents-20230627/, 27 June 2023

Exclusion Draft: Document Object Model (DOM) Level 3 Events Specification, https://www.w3.org/TR/2012/WD-DOM-Level-3-Events-20120906/, 06 September 2012, Exclusion Draft began on 6 Sep 2012; ended on 5 November 2012.

Exclusion Draft Charter: https://www.w3.org/2012/webapps/charter/

UI Events KeyboardEvent code Values

This specification defines the values for the KeyboardEvent.code attribute, which is defined as part of the UI Events Specification [UIEvents]. The code value contains information about the key event that can be used to identify the physical key being pressed by the user.

Draft state: Candidate Recommendation Snapshot

Expected completion: CR - Q3 2023; REC - Q1 2024

Adopted Draft: UI Events KeyboardEvent code Values, https://www.w3.org/TR/2023/CR-uievents-code-20230530/, 30 May 2023

Exclusion Draft: UI Events KeyboardEvent code Values, https://www.w3.org/TR/2023/CR-uievents-code-20230530/, 30 May 2023, Exclusion Draft began on 30 May 2023; will end on 29 July 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

UI Events KeyboardEvent key Values

This specification defines the key attribute values that must be used for KeyboardEvent's key attribute, which is defined as part of the UI Events Specification [UIEvents].

Draft state: Candidate Recommendation Snapshot

Expected completion: CR - Q3 2023; REC - Q1 2024

Adopted Draft: UI Events KeyboardEvent key Values, https://www.w3.org/TR/2023/CR-uievents-key-20230530/, 30 May 2023

Exclusion Draft: UI Events KeyboardEvent key Values, https://www.w3.org/TR/2023/CR-uievents-key-20230530/, 30 May 2023, Exclusion Draft began on 30 May 2023; will end on 29 July 2023.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

Web Share API

This specification defines an API for sharing text, links and other content to an arbitrary destination of the user's choice.

The available share targets are not specified here; they are provided by the user agent. They could, for example, be apps, websites or contacts.

Draft state: W3C Recommendation

Expected completion: REC - 2023; Future updates to this Recommendation may incorporate new features.

Adopted Draft: Web Share API, https://www.w3.org/TR/2023/REC-web-share-20230530/, 30 May 2023

Exclusion Draft: Web Share API, https://www.w3.org/TR/2022/CR-web-share-20220830/, 30 August 2022, Exclusion Draft began on 30 Aug 2022; ended on 29 October 2022.

Exclusion Draft Charter: https://www.w3.org/2022/04/webapps-wg-charter.html

Screen Wake Lock API

This document specifies an API that allows web applications to request a screen wake lock. Under the right conditions, and if allowed, the screen wake lock prevents the system from turning off a device's screen.

Draft state: Working Draft

Expected completion: CR - Q2 2024; REC - Q4 2024

Adopted Draft: Screen Wake Lock API, https://www.w3.org/TR/2023/WD-screen-wake-lock-20230406/, 06 April 2023

Exclusion Draft: Wake Lock API, https://www.w3.org/TR/2017/CR-wake-lock-20171214/, 14 December 2017, Exclusion Draft began on 14 Dec 2017; ended on 12 February 2018.

Exclusion Draft Charter: https://www.w3.org/2016/03/device-sensors-wg-charter.html

DeviceOrientation Event Specification

This specification defines several new DOM events that provide information about the physical orientation and motion of a hosting device.

Draft state: Working Draft

Expected completion: CR - Q2 2024; REC - Q4 2024

Adopted Draft: DeviceOrientation Event Specification, https://www.w3.org/TR/2023/WD-orientation-event-20230421/, 21 April 2023

Exclusion Draft: DeviceOrientation Event Specification, https://www.w3.org/TR/2016/CR-orientation-event-20160818/, 18 August 2016, Exclusion Draft began on 18 Aug 2016; ended on 17 October 2016.

Exclusion Draft Charter: https://www.w3.org/2014/04/geo-charter.html

Geolocation API

The Geolocation API provides access to geographical location information associated with the hosting device.

Draft state: W3C Recommendation

Expected completion: REC - 2022

Adopted Draft: Geolocation API, https://www.w3.org/TR/2022/REC-geolocation-20220901/, 01 September 2022

Exclusion Draft: Geolocation API, https://www.w3.org/TR/2022/CR-geolocation-20220217/, 17 February 2022, Exclusion Draft began on 17 Feb 2022; ended on 18 April 2022.

Exclusion Draft Charter: https://www.w3.org/2020/11/das-wg-charter.html

Notes

List of Notes produced by the Web Applications Working Group.