iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: https://www.w3.org/2022/06/html-wg-charter.html
HTML Working Group Charter

HTML Working Group Charter

The mission of the HTML Working Group is to give input to and bring the WHATWG HTML and DOM Review Drafts to W3C Recommendations.

Join the HTML Working Group.

Start date 06 June 2022
End date 06 December 2024
Chairs Theresa O'Connor (Apple, Inc.), Léonie Watson (TetraLogical)
Team Contacts Michael Smith (0.05 FTE), Xiaoqian Wu (0.05 FTE)
Meeting Schedule Teleconferences: The HTML Working Group expects to work mostly asynchronously. The chairs may call regular or topic-specific teleconferences.
Face-to-face: may be scheduled by consent of the participants.

Scope

In accordance with the WHATWG-W3C Memorandum of Understanding and 2021 Relationship Update, 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 Working Group also has the ability to bring the Fetch review drafts to Recommendation. The Working Group may also work on extension specifications for HTML features in coordination with the WHATWG Steering Group.

The community (including users, implementers, and developers) and horizontal review groups are encouraged to contribute directly to the WHATWG HTML, DOM, and Fetch 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.

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 Working Group will deliver the following W3C normative specifications based on WHATWG Living Standards:

HTML

Along with defining the HTML markup language, this specification also defines many of the core requirements that form the basis of the Web runtime.

Draft state: WHATWG Living Standard

Expected W3C Recommendation: yearly basis

DOM

This specification defines a platform-neutral model for events, aborting activities, and node trees.

Draft state: WHATWG Living Standard

Expected W3C Recommendation: yearly basis

Fetch

This specification defines requests, responses, and the process that binds them: fetching.

Draft state: WHATWG Living Standard

The Working Group will work on the following extension specifications on the Recommendation Track:

W3C HTML Ruby Markup Extensions

This specification extends and refines the facilities provided by HTML to support “Ruby”, which is a form of interlinear annotations commonly used in East Asia, primarily (but not exclusively) for phonetic assistance. The minimal ruby markup model currently described in the HTML Living Standard is insufficient to satisfy known ruby use cases and accessibility requirements. This extension specification (which may be split into multiple “levels” based on feature implementation status) will describe a more complete model based on prior work by the W3C HTML, i18n, and CSS Working Groups, and consultation with the accessibility community in East Asia. See https://github.com/whatwg/sg/issues/184 for the rationale leading to developing this as an extension specification.

WHATWG coordination: Agreement on HTML Ruby Markup

Draft state: W3C Working Group Note (See also related content in: WHATWG Living Standard, Pull Request)

Adopted Draft: https://www.w3.org/TR/2013/WD-html-ruby-extensions-20131022/

Exclusion Draft: https://www.w3.org/TR/2013/WD-html-ruby-extensions-20131022/
Exclusion period began 22 October 2013; exclusion period ended 21 March 2014.

Exclusion Draft Charter: https://www.w3.org/2007/03/HTML-WG-charter.html

Timeline

This is the annual timeline of the Working Group.

  • January: REC for DOM
  • February: Wide review for HTML
  • May: CR for HTML
  • July: PR for HTML
  • July: Wide review for DOM
  • August: REC for HTML
  • October: CR for DOM
  • December: PR for DOM

Work Mode

When WHATWG publishes a Review Draft of its HTML or DOM Living Standards, the HTML Working Group may request endorsement of this Review Draft as a CR, PR, and/or REC. The Working Group works to demonstrate to the Director that the contents of the WHATWG Review Draft have had wide review, issues have been addressed, and the contents have sufficient CR exit criteria as defined by W3C Process. The Working Group will look for a consensus of its participants to advance each Review Draft as a CR and will have worked to engage the community to make this consensus achievable.

When there is an unresolved objection, the Working Group will make substantial effort to resolve the conflict so that W3C can publish a REC with no normative differences from the WHATWG Review Draft of an HTML or DOM specification. If the Working Group cannot reach consensus to bring a desired Review Draft forward on the REC track, it must ensure that appropriate issues are raised or encourage the WHATWG editors to re-open issues in the WHATWG repository.

If unresolved differences remain, the Working Group will take the following escalation steps, each step to be reached only once the preceding steps have been given good faith efforts to reach consensus:

  1. The Working Group shall attempt to resolve the objection, working to explain its members’ concerns to the WHATWG editors and other Workstream participants (through the WHATWG GitHub repository) and to explain the decision of the WHATWG to those raising the concerns;
  2. The Working Group shall escalate the disagreement to the WHATWG Steering Group to help resolve the issue;
  3. The Working Group shall explore techniques other than having a HTML or DOM specification with normative differences such as an extension specification; or as non-normative advice;
  4. The Working Group may request technical advice from the TAG. The TAG may consult other experts, including for expertise not currently available on the TAG. The TAG may be able to find some consensus or explain to one side or the other any negative impacts of their position;
  5. The issue shall go to the W3C Director, who examines the arguments using the record of the tracked issue, the Working Group analysis, and the TAG analysis.
    1. If the Director overrules the objections, then W3C continues its process to publish the HTML or DOM Review Draft as a REC;
    2. If the Director sustains the objection, the Director and/or the TAG may choose to re-open the appeal to the WHATWG Steering Group with any new data or rationale;

The HTML Working Group is expected to endorse a WHATWG HTML or DOM Review Draft to Candidate Recommendation at least once per 12 month period.

For extension specifications, while coordination as agreed with the WHATWG is also expected, the Working Group will follow the more standard approach to technical report development and publication: the Working Group will appoint its own editors, develop its own drafts, accept and process feedback, and progress the documents along the Recommendation Track on the basis of its own consensus.

Success Criteria

The Working Group will bring one or more WHATWG Review Drafts from W3C Candidate Recommendation to Proposed Recommendation.

In order to advance WHATWG Review Drafts to Candidate Recommendation (CR), each feature is expected to be marked with its implementation status. The CR will indicate that all features with fewer than two implementations are at-risk.

The Proposed Recommendation (PR) and Recommendation (REC) endorsement of WHATWG Review Drafts will indicate that all features which do not have at least two independent implementations are considered informative, not normative, for W3C purposes.

In order to advance to Proposed Recommendation, each extension specification is expected to have at least two independent implementations of every feature defined in the specification.

Each specification is encouraged to contain or point to considerations detailing all known security and privacy implications for implementers, Web authors, and end users.

Each specification is encouraged to contain or point to information describing accessibility implications for implementers, Web authors, and end users; and point to guidance on how specification features can be used to maximize accessibility in implementations.

Coordination

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

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

W3C Groups

Accessible Rich Internet Applications (ARIA) Working Group
To collaborate on enhancing the accessibility of web content through the development of supplemental attributes, that can be applied to native host language elements and exposed via platform accessibility APIs.
Accessible Platform Architectures Working Group
For accessibility horizontal review, and to collaborate on accessibility related topics.
Web Applications Working Group
For the mapping of HTML elements and attributes to platform accessibility APIs, as well as the the author conformance requirements for setting ARIA attributes.
Web Performance
For its work on page visibility, cooperative scheduling of background Tasks, preloading, and resource hints.
Media Working Group
This Working Group extends the HTMLMediaElement interface defined in HTML to allow JavaScript to generate media streams for playback, such as Media Source Extensions.
Web Application Security Working Group
Specifications such as CSP provide inputs into the algorithms defined by the Fetch specification.

External Organizations

WHATWG
The Web Hypertext Application Technology Working Group (WHATWG) is a community of people interested in evolving the web through standards and tests. HTML and DOM are developed principally in the WHATWG, in the WHATWG HTML and DOM workstreams.

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.

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 HTML Working Group home page.

Most HTML 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 in WHATWG GitHub repositories. It may also use the public mailing list public-html@w3.org (archive).

For extension specifications, this group primarily conducts its technical work through its own GitHub repositories. The public is invited to review, discuss and contribute to this work.

Decision Policy

For the purpose of following its work mode, this group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, a participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

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

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

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue 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 W3C Patent Policy Implementation.

Contributions to the WHATWG HTML and DOM workstreams are covered by the WHATWG Intellectual Property Rights Policy. W3C will rely on that policy for assurance when advancing Review Drafts to Recommendations.

Licensing

This Working Group will use the CC-BY license, and follow the terms of WHATWG-W3C Memorandum of Understanding and 2021 Relationship Update

About this Charter

This charter has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

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

Charter Period Start Date End Date Changes
Initial Charter 6 June 2019 14 December 2020 none
Rechartered 15 December 2020 1 June 2021

Switched to Patent Policy 2020

Charter Extension 1 June 2021 1 September 2021 None
Charter Extension 1 September 2021 30 November 2021 None
Charter Extension 10 November 2021 31 January 2022 None
Charter Extension 31 January 2022 30 April 2021 None
Charter Extension 14 April 2021 30 June 2021 None
Rechartered 6 June 2022 6 June 2024

Update to the WHATWG MOU. Added Fetch and Ruby Markup Extensions.

Charter Extension 12 June 2024 06 December 2024 None

Change log

Changes to this document are documented in this section.