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.
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:
- Haptic input devices and their emitted events and/or data.
- Data sharing across remote and local web applications.
- Receiving and acting upon data from remote sources.
- Accessing the file system and persistent storage.
- Interfacing with OS capabilities.
- Integrating web applications with the OS.
- Preventing the screen from turning off under certain conditions.
- Obtaining and providing the location of the hosting device.
- Reacting to changes in motion and orientation of the hosting device.
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. More information about these specifications can be found in the detailed list of Deliverables.
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. |
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. |
WICG specifications
Depending on the WICG progress, including interest from multiple implementers, the Group may also produce W3C Recommendation-track documents 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 | 14 April 2022 | 14 April 2024 |
|
Rechartered | TBD | TBD |
|
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-contact-picker-20231013/, 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-contact-picker-20231013/, 13 October 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 theFile Upload
state [HTML]. -
A
Blob
interface, which represents immutable raw binary data, and allows access to ranges of bytes within theBlob
object as a separateBlob
. -
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 aFile
or aBlob
, 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 overloadedsend()
method forFile
orBlob
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 theinput
element when it is in theFile 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-20231005/, 05 October 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-20230808/, 8 August 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/2023/WD-intersection-observer-20231018/, 18 October 2023
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/2023/WD-push-api-20231010/, 10 October 2023
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-20230809/, 09 August 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-20231028/, 28 October 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/
- 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-20230915/, 15 September 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
'skey
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-20231107/, 07 November 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-20231110/, 10 November 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.
- Web App Manifest - Application Information
-
This document is a registry of supplementary members for the Web Application Manifest specification that provide additional metadata to an application manifest. This metadata can be used in a digital storefront or other surfaces where this web application may be marketed or distributed, or to enhance an installation dialog when installing a web application.
Draft state: Group Note
Expected completion: CR - Q4 2024; REC - Q4 2025
Adopted Draft: Web App Manifest - Application Information, https://www.w3.org/TR/2023/NOTE-manifest-app-info-20230821/, 21 August 2023