W3C

The mission of the Browser Testing and Tools Working Group is to produce technologies for use in testing, debugging, and troubleshooting of Web applications running in Web browsers.
 
The scope of the Browser Testing and Tools Working Group includes protocols and APIs for the purpose of automating testing of Web applications running in browsers—for example, to simulate user actions such as clicking links, entering text, and submitting forms.

The mission of the group is to develop and maintain CSS.
 
Cascading Style Sheets (CSS) is a style sheet language that allows authors and users to attach style (e.g., from fonts and spacing to filter effects and style animations) to structured documents and Web applications. By separating the presentation style from the content, CSS simplifies Web authoring and site maintenance. It supports media-specific style so that authors may tailor the presentation to different devices and capabilities.
 
The CSS WG develops a single deliverable, the CSS specification. It consists of the following, somewhat independent technologies, all of which are in scope for the CSS Working Group:

• A syntax for associating information with elements in a structured resource, in particular HTML and SVG documents. The main part of the syntax consists of rules that associate properties + values with selectors where the selectors are expressions that match elements in the structured document, based on their position in the document or based on other information about the elements (their type, what the user has done with them, etc.)
• A processing model, referred to as “cascading and inheritance,” that ensures that, given one or more style sheets and a structured document, each element in the document is associated with the full set of properties and values, no matter how short the style sheets or how long the document.
• A rendering model, part of which is a model of typography, i.e., a layout model for text documents, possibly with embedded other objects and possibly involving several documents simultaneously. The model describes blocks and lines of text, characters, columns, colors, dynamic effects, etc. It also includes the presentation and behavior of UI widgets. CSS's influence over UI controls is limited to defining the look of controls in various states during interaction (valid/invalid, required, inactive, etc.), hiding/unhiding, and other local behaviors, but CSS does not itself change the state of elements and does not define how (form) elements interact with a server. (The general principle is that CSS can enhance the user's interaction with a document, but the document should ideally be functional without it.)
• The CSS Object Model, a set of standard APIs, to which libraries can be written for manipulating style sheets and documents with associated style information.

The CSS WG not only develops CSS, but also checks that properties needed by other working groups and which could occur in a style sheet together with CSS properties, are compatible with CSS in general and consistent in their naming schemes. This affects properties such as those of SVG and Device Independence (such as media features).
 
Part of the work of the working group is also to develop test suites for the various specifications it publishes.
 
Another part is to maintain errata and, when needed, publish revised versions of the various specifications.

The mission of the Dataset Exchange WG is to: 1. Revise the Data Catalog Vocabulary, DCAT, taking account of related vocabularies and the extensive work done in developing a number of its application profiles. 2. Define and publish guidance on the use of application profiles when requesting and serving data on the Web.
 
DCAT is formulated as an RDF vocabulary and is expected to remain so, however, the working Group is agnostic about data formats. Methods for expressing DCAT in other (existing) formats are in scope.
 
Government data, scientific research data, industry/enterprise and cultural heritage data, whether shared openly or not, are all explicitly in scope.

The mission of the Decentralized Identifier Working Group is to standardize the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications.
 
The design approach for the DID specification is the same as the URI specification (RFC 3986). RFC 3986 defines the generic syntax for URIs, and all URI schemes are separate specifications. In fact, the DID specification is a conformant URI scheme. The goal of the DID specification is to do exactly the same for DIDs, that is, for this Working Group to define the generic DID specification, and then for others to define DID Method specifications.
 
The Working Group will:

1. Define the DID URI scheme.
2. Recommend a data model and syntax(es) for the expression of Decentralized Identifier Documents, including one or more core vocabularies.
3. Recommend a set of requirements for DID Method specifications that are conformant with the data model and syntax(es). The DID Method specification authoring requirements will recommend a list of mandatory and optional operations, with associated descriptions, which are expected to be defined in DID method specifications.
4. Provide a rubric of decentralized characteristics for DID Method specifications. This allows the DID Method specifications to self-certify, or independent third parties to evaluate, the DID Method specification's level of adherence to principles of decentralization.
5. Concentrate their efforts on the initial use cases with a particular focus on enabling future specification and implementation of Identity and Access Management. Use cases from other industries may be included if there is significant industry participation.
6. Define extension points enabling authentication, signing and cryptography mechanisms, but not defining specific authentication, signing, or cryptography mechanisms. (See "Out of Scope".)
7. With the initial use cases document as input, the WG will produce a NOTE at the end of the process that is a refined Use Cases document.
8. Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.

The mission of the Device and Sensors Working Group is to create client-side APIs that enable the development of Web Applications that interact with device hardware, sensors, services and applications such as the camera, microphone, proximity sensors, native address books, calendars and native messaging applications.
 
The scope of this Working Group is the creation of API specifications for a device’s services that can be exposed to Web applications. Services include sensors, media capture, network information and discovery. Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.
 
Hardware security services are out of scope for this group.
 
Priority will be given to developing simple and consensual APIs, leaving more complex features to future versions.

The mission of the Distributed Tracing is to define standards for interoperability between tracing tools.
Modern cloud-native applications are highly distributed and often span multiple technology and vendor boundaries. The complexity of these applications requires a detailed understanding of how individual requests are executed. This is referred to as "tracing".
Tracing tools for collecting this information have been available for quite some time. However, these tools have not been built with interoperability in mind. This leaves the developer with a number of challenges in getting an end-to-end trace of complex transactions:

• Traces are often broken, because trace context information is lost in a contributing tier or the trace is restarted
• Vendors cannot pass proprietary information across tiers instrumented with a different implementation and therefore lose relevant information (e.g. step count, server information, ...)
• End users don't have the ability to create complete end-to-end traces of application transactions which are monitored by different tools, as there is no defined data format and semantics for trace data

The scope of this working group is the definition of data formats and headers enabling the propagation and correlation of tracing data across different implementations.

The mission of the Education and Outreach Working Group is to develop strategies and resources to promote awareness, understanding, implementation, and conformance testing for W3C accessibility standards; and to support the accessibility work of other W3C Groups.
 
In accordance with the WHATWG-W3C Memorandum of Understanding, this group is chartered to assist the W3C community in raising issues and proposing solutions in the WHATWG HTML and DOM workstreams, and to bring WHATWG HTML and DOM Review Drafts to Recommendation.
 
The community (including users, implementers, and developers) and horizontal review groups are encouraged to contribute directly to the WHATWG HTML and DOM repositories; raising issues, proposing solutions, commenting on proposed solutions, and indicating support or otherwise for proposals. In the event that a person raising an issue feels that the issue has not been fairly resolved by WHATWG, the HTML Working Group may help to explain the resolution and attempts to work with the person and the WHATWG editors to achieve consensus, as detailed in the Group work mode.

The mission of the Immersive Web Working Group is to help bring high-performance Virtual Reality (VR) and Augmented Reality (AR) (collectively known as XR) to the open Web via APIs to interact with XR devices and sensors in browsers.
 
The Immersive Web Working Group will develop standardized APIs to provide access to input and output capabilities commonly associated with XR hardware such as Google’s Daydream, the Oculus Rift, the Samsung GearVR, the HTC Vive, and Windows Mixed Reality headsets and sensors as well as mobile handheld devices and standalone headsets such as the Oculus Go. The WG will develop APIs to enable the creation of XR web experiences that are embeddable in the Web of today, enabling progressive enhancement of existing sites.
 
The scope of the Immersive Web Working Group charter is to define APIs which:

• Detect available XR devices and sensors.
• Query XR devices for device-specific capabilities.
• Receive updated information about the device's position and orientation over time.
• Receive updated information about the device's environment.
• Present imagery to the device at the device's native frame rate, using the device’s position and orientation over time to provide an immersive experience.
• Provide information about XR-specific input, including tracked controller state and hand gesture.
• For augmenting reality on devices which support AR, enable XR sessions that provide real-world display, and provide the ability to hit-test surfaces in the real world.

The mission of the Internationalization Working Group is to enable universal access to the World Wide Web by proposing and coordinating the adoption by the W3C of techniques, conventions, technologies, and designs that enable and enhance the use of W3C technology and the Web worldwide, with and between various different languages, scripts, regions, and cultures.

• Technical issues related to internationalization and universal access across the globe. The Working Group provides advice and assistance related to internationalization, encompassing work related to international, linguistic, cultural, and writing system variations affecting W3C technologies. This advice should be provided to W3C Working Groups as early as possible in the development of specifications. The Working Group also tracks developments outside the W3C which have a bearing on the international Web, such as Unicode, IDN/ICANN issues, language tag and IRI developments at the IETF, JavaScript, etc.
• Reviews and discussion of W3C technologies for internationalization issues, as these technologies develop. This encompasses a broad array of cultural, linguistic, technical and accessibility concerns. Review work may also include standards created by external standards bodies and organizations related to internationalization, if it is thought to be relevant to W3C technology. The Working Group maintains liaison relationships with these groups to ensure coordinated, consistent development of these standards.
• Gathering requirements for linguistic support. The Working Group supports groups documenting typographic and other requirements for scripts and languages around the world, with a view to informing specification developers and browser/ebook implementers about what needs to be supported.
• Outreach and inreach, in the forms of notes, articles, tutorials, presentations, tests and other resources to help specification writers, web masters, content authors, and others involved in developing and implementing the Web understand the issues involved and the techniques available with regard to supporting international use of Web technology.
• Implementation support and guidance. The WG produces tests for international features of the Web Platform, and provides advice and support to browser/ebook implementers to assist in the adoption of those features.

The formal documents produced by the Working Group are guidelines, best practices, requirements, and the like. These are best published as Working Group Notes. The Working Group will not produce Rec-track specifications, with the exception of maintaining the following W3C Recommendations:
 
Internationalization Tag Set (ITS) Version 1.0 and Version 2.0

• These specifications define data categories and their implementation as a set of elements and attributes. ITS 2 adds additional concepts that are designed to foster the automated creation and processing of multilingual Web content.

Character Model for the World Wide Web 1.0: Fundamentals

• It provides authors of specifications, software developers, and content developers with a common reference for interoperable text manipulation on the World Wide Web

Ruby Annotation

• "Ruby" are short runs of text alongside the base text, typically used in East Asian documents to indicate pronunciation or to provide a short annotation. This specification defines markup for ruby.

Since its original publication in 2014 by the RDF 1.1 Working Group, JSON-LD 1.0 has become an essential format for describing structured data on the World Wide Web. It is estimated to be used by between 10% and 18.2% of all websites. This is due largely to its adoption as a recommended format by schema.org. It has been adopted by several Recommendations including those from the Social Web, Web Annotation, and Linked Data Platform Working Groups, and current Working Groups have expressed interest in alignment of their specifications, such as the Publishing and Web of Things Working Groups. It has provided a much-needed bridge between communities that need rich semantics, and those that desire an intuitive and easily usable format (see separate wiki page for more details).
 
The mission of the JSON-LD Working Group is to update the JSON-LD 1.0 specifications to address specific usability or technical issues based on the community’s experiences, implementer feedback, and requests for new features.
 
The JSON-LD Working Group will update the JSON-LD 1.0 Recommendation to take into account new features and desired simplifications that have become apparent since its publication. The group will also extend the JSON-LD 1.0 Processing Algorithms and API Recommendation to update the existing APIs corresponding to changes in the JSON-LD Recommendation. Additionally, the group will move the Framing API CG specification to W3C Recommendation.
 
A summary of syntax changes proposed for inclusion by the JSON for Linking Data Community Group can be found on a wiki and in slides used at TPAC 2017.
 
The work must be consistent with principles expressed in the Data on the Web Best Practices Recommendation. All changes must preserve backward compatibility for JSON-LD 1.0 documents. This means that, when processing existing JSON-LD documents, JSON-LD 1.1 processors generate the same expanded output, unless that output is subject to errata in JSON-LD 1.0 or is otherwise an unspecified implementation detail.

The mission of the Media Working Group is to develop and improve client-side media processing and playback features on the Web.
 
Standardization efforts to develop media foundations for the Web, such as the HTMLMediaElement interface and Media Source Extensions, have helped turn the Web into a major platform for media streaming and media consumption. Building on the experience gained through implementation, deployment and usage of these technologies, and on incubation discussions within the Web Platform Incubator Community Group, the Media Working Group will extend media foundations with new standardized technologies to improve the overall media playback experience on the Web.
 
The scope of the Media Working Group is:

• Detection of media capabilities
• Detection of the autoplay policy
• Statistics on perceived playback quality
• Generation of media streams for playback
• Playback of encrypted content
• Exposure of media features at the system level to Web applications (e.g. access to platform media keys, display of media metadata at the system level, creation of an always-on-top video window) to Web applications
• Exposure of metadata event tracks synchronized to audio or video media

The mission of the WebAssembly Working Group is to standardize a size- and load-time-efficient format and execution environment, allowing compilation to the web with consistent behavior across a variety of implementations.
 
The scope of the WebAssembly Working Group comprises addressing the need for native-performance code on the Web in applications ranging from 3D games to speech recognition to codecs—and in any other contexts in which a common mechanism for enabling high-performance code is relevant—by providing a standardized portable, size-, and load-time-efficient format and execution environment that attempts to maximize performance and interoperate gracefully with JavaScript and the Web, while ensuring security and consistent behavior across a variety of implementations.
 
Since the inception of the Web, various technologies have been developed to allow “native” applications on the Web. Techniques such as user consent with digital signatures and Virtual Machines with different capabilities than JavaScript failed to be robust in the face of increasingly high security requirements. Later efforts like Native Client, which featured robust security, failed to achieve cross-browser adoption. Cross-compilation to JavaScript using Emscripten, especially using the machine-optimization subset called asm.js, achieved some degree of success. However, consistent cross-browser performance, shared memory threads, and other machine features have proved elusive.
 
The WebAssembly format and execution environment address the shortcomings of those previous efforts.