Information coding

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 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 Automotive Working Group is to develop Open Web Platform specifications for application developers, including but not limited to HTML5/JavaScript, enabling Web connectivity through in-vehicle infotainment systems and vehicle data access protocols. The API is agnostic with regard to the connection used.
 
This group will develop service specifications for exposing vehicle data and other information around vehicle centric functions.
 
A common pattern will be described to unify the style the different service interfaces are using.
 
The specification(s) produced by this Working Group will include security and privacy considerations.
 
Members of the Working Group should review other working groups' deliverables that are identified as being relevant to the Working Group's mission.
 
Services may include but are not limited to

• Vehicle Data
  • vehicle brand, model, year, fuel type, transmission type, steering wheel position, tire pressure, oil level, wiper position, lights, doors, windows and seat settings as well as navigation, trip computer data, climate control data, speed, RPMs, acceleration, gears, …
• media
  • media control, track lists, …
• navigation
  • route manipulation, points of interests, …

The mission of the Audio Working Group is to add advanced sound and music synthesis capabilities to the Open Web Platform.
 
Building upon and expanding the basic functionalities brought by HTML5's and media elements and MediaStream object, the Audio Working Group defines client-side script APIs which support the features required by rich interactive applications including the ability to process and synthesize audio streams directly in script, as well as giving access to musical instruments through a bridge with existing system-level MIDI APIs.
 
The audio API provides methods to read audio samples, write audio data, create sounds, and perform client-side audio processing and synthesis with minimal latency. It also adds programmatic access to the PCM audio stream for low-level manipulation directly in script. This API can be used for interactive applications, games, 3D environments, musical applications, educational applications, and for the purposes of accessibility. It includes the ability to synchronize, visualize, or enhance sound information when used in conjunction with graphics APIs. Sound synthesis can be used to enhance user interfaces, or produce music. The addition of advanced audio capabilities to user agents presents new options to Web developers and designers, and has many accessibility opportunities and challenges that this working group will continue to keep in mind.
 
In addition to an audio processing API, this group has received feedback from the audio and music community and industry, who wish to Web-enable their MIDI-capable devices. MIDI is an electronic device interface, developed by the musical instrument industry, that includes communication protocols for two-way connection and control of a wide variety of devices, including digital musical instruments, digital audio workstations, lighting sytems, game controllers, and many other systems. The MIDI specification has wide adoption and interoperable deployment across devices and computer operating systems, and to extend this existing infrastructure, the Audio Working Group is also developing a specification to create a bridge between the browser and existing system-level MIDI APIs, to make musical instruments first-class citizens of the Web.
 
The scope of this working group includes:

• Developing a client-side script API for processing and synthesizing PCM audio streams, including direct scripted solutions.
• Access to audio devices, such as for microphones or other audio inputs, and multi-channel speakers or other audio outputs.
• APIs and advanced functionality regarding audio cache management and audio capability information.
• Defining a client-side script API for accessing and manipulating MIDI-capable devices available on the users' systems.

This working group will take into account common work-flows for sound creators, including considerations for common audio formats. This group will also liaise with other groups for direct connection to audio inputs, such as microphones and speakers.
 
The HTML5 specification introduces the

The mission of the Accessible Rich Internet Applications Working Group (ARIA WG, formerly part of the Protocols and Formats Working Group) is to develop technologies that enhance accessibility of web content for people with disabilities. This includes continued development of the Accessible Rich Internet Applications (WAI-ARIA) suite of technologies and other technical specifications when needed to bridge known gaps.
 
The scope of the working group is

• Continue development of existing ARIA specifications to address needs reported by authors and to achieve parity with native host languages, creating new ARIA specifications where necessary;
• For each ARIA specification developed by this Working Group, create a corresponding Accessibility API Mappings specification defining the correct exposure for each platform;
• For all attributes defined by this Working Group, document best practices for authors;
• Collaborate with other groups to create mapping specifications for native host language semantics;
• Develop testing tools which can be used to verify accessibility implementations by examining the mappings exposed via platform accessibility APIs;
• Collaborate with other groups involved in defining ARIA techniques and implementing ARIA support.

The mission of the Accessible Platform Architectures Working Group (APA WG) is to ensure W3C specifications provide support for accessibility to people with disabilities. The group advances this mission through review of W3C specifications, development of technical support materials, collaboration with other Working Groups, and coordination of harmonized accessibility strategies within W3C.
 
The scope of the working group is

• Support W3C Working Groups and external organizations collaborating on web technologies to create technical specifications that provide features needed for accessibility to people with disabilities:
  • Provide expertise to the W3C about the needs of users with disabilities, including both serving as a resource base and providing educational in-reach to the W3C community as needed;
  • Review W3C requirements and specifications (accessibility horizontal reviews, AHR) as needed to identify accessibility issues and make recommendations to the appropriate Working Group, particularly at the First Public Working Draft and Last Call or Candidate Recommendation stages and when explicit milestone review readiness is signaled;
  • Work closely with Working Groups when needed to help them architect their specifications to support, and not unknowingly interfere with, accessibility;
• Develop and publish explanatory information about accessibility of web technology:
  • Document concrete guidance about how to ensure technical specifications appropriately support accessibility;
  • Collect information about technology features, implementation, and usage patterns to institutionalize W3C knowledge about present-day accessibility problems, including for emerging technologies such as social networking, real-time communications, Web-based television viewing, etc.;
• Explore new technologies and accessibility challenges and begin to develop remediation approaches:
  • Leverage existing W3C markup technologies to produce new specifications or additions to existing specifications which support content personalization for various identified accessibility requirements;
  • Determine accessibility considerations for new devices and technologies, such as artificial intelligence, authentication, automotive interfaces, digital publications, graphics and media, mobile communications devices, payments, tablets, virtual and augmented and mixed reality, Web-enabled television, Web of Things, etc.;
  • Identify gaps and questions from accessibility specification reviews that may need research, and articulate findings and specific questions for discussion in various additional fora;
• Coordinate with other accessibility stakeholders (including other WAI groups, accessibility proponents in other groups, and external accessibility organizations) to develop harmonized accessibility guidance across W3C:
  • Coordinate with accessibility proponents in W3C technical groups to help ensure accessibility solutions are developed in a consistent manner across technologies and to ensure that accessibility needs are addressed at an appropriate part of the technology stack;
  • Involve accessibility proponents in other fora - such as the WAI Interest Group, community groups, coordination activities, and other centers of expertise - to maximize the knowledge and impact brought to the group's activities;
  • Advocate creation and reuse of common implementations of functions that are required by accessibility;
  • Review non-W3C technologies that impact the accessibility of W3C technologies;
  • Strategize solutions within W3C and via liaisons with external organizations.

The mission of the Accessible Rich Internet Applications Working Group is to enhance the accessibility of web content through the development of supplemental attributes, including roles, states, and other properties, that can be applied to native host language elements and exposed via platform accessibility APIs.
 
The scope of the working group is

• Continue development of existing ARIA specifications to address needs reported by authors and to achieve parity with native host languages, creating new ARIA specifications where necessary;
• For each ARIA specification developed by this Working Group, create a corresponding Accessibility API Mappings specification defining the correct exposure for each platform;
• For all attributes defined by this Working Group, document best practices for authors;
• Collaborate with other groups to create mapping specifications for native host language semantics;
• Develop testing tools which can be used to verify accessibility implementations by examining the mappings exposed via platform accessibility APIs;
• Collaborate with other groups involved in defining ARIA techniques and implementing ARIA support.

The purpose of the XDI TC is to define a format and protocol for semantic data interchange using a standard addressable semantic graph model serialized in JSON.
 
For more information, see the TC Charter and FAQ.
 
The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken at those meetings.

Human experts in specific IT infrastructure and business domains possess substantial knowledge about prevention, remediation, and optimization of systems. However, there is a significant challenge in capturing, combining, and leveraging this siloed knowledge across domains.
 
SAF is a catalog-based XML collaborative knowledge framework that is designed to address these challenges by automating appropriate responses to changing business conditions and integrating contributions from diverse domains to provide competitive advantage. SAF has applicability in IT and business including cloud computing, service management, governance, security, energy, eGov, financial, emergency management, healthcare, and communications.
 
Cloud computing, in particular, exacerbates the separation between consumer-based business requirements and provider-supplied IT responses. SAF facilitates knowledge sharing across these domains, allowing consumer and provider to work cooperatively together to ensure adequate capacity, maximize quality of service, and reduce cost. The SAF technical committee considers cloud computing to be an area where the value of existing and developing standards could be significantly enhanced using SAF.
 
For more information on SAF, see the TC Charter, the FAQ, and the (working) Symptoms Automation Framework Documents.

The Swordfish Scalable Storage Management API ("Swordfish") uses RESTful interface semantics and a standardized data model to provide a scalable, customer-centric interface for managing storage and related data services.

The SOA Repository Artifact Model and Protocol (S-RAMP) TC defines a common data model for SOA repositories as well as an interaction protocol to facilitate the use of common tooling and sharing of data. The TC will define an ATOM binding which documents the syntax for interaction with a compliant repository for create, read, update, delete and query operations.

The Auditorium Security Message (ASM) specification enables interoperable communication of security-critical information (information necessary to ensure security of D-Cinema content) between devices over an intra-theater exhibition network.