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.
|Start date||06 June 2019|
|End date||01 June 2021|
|Charter extension||See Change History.|
|Chairs||Theresa O'Connor (Apple, Inc.), Léonie Watson (TetraLogical)|
|Team Contacts||Michael Smith (0.05 FTE), Xiaoqian Wu (0.05 FTE)|
Teleconferences: The HTML Working Group expects to work mostly asynchronously. The chairs
may call regular or topic-specific teleconferences.
Face-to-face: we should meet during the W3C's annual Technical Plenary week. Additional face-to-face meetings are unlikely, but may be scheduled by consent of the participants.
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 Working Group will bring one or more WHATWG Review Drafts from W3C Candidate Recommendation to Proposed Recommendation.
In order to advance 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 will indicate that all features which do not have at least two independent implementations are considered informative, not normative, for W3C purposes.
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.
This Group expects to advance periodic revisions of HTML and DOM to Recommendation.
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.
The Working Group will deliver the following W3C normative specifications:
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 first W3C Recommendation: Q1 2020
This specification defines a platform-neutral model for events, aborting activities, and node trees.
Draft state: WHATWG Living Standard
Expected first W3C Recommendation: Q1 2020
The Working Group may also maintain an errata page for each W3C Recommendation, with errata generated from the relevant pull requests in the WHATWG repositories.
The Working Group may also publish HTML or DOM extension specifications.
As the W3C Process requires implementation experience to advance beyond CR, while WHATWG process requires only implementation commitments, WHATWG Review Drafts endorsed as CR, PR, and/or REC will include feature implementation status annotations in the margin. The granularity of the annotations should be such that they can be reasonable indicators of which features have implementation experience. The status indicators will be sourced from an external site or set of test cases, such as caniuse or wpt.fyi. The CR endorsement will mention that all features that do not have two implementations according to the annotations are at risk. The PR and REC endorsement will mention that all features which do not have two implementations are considered informative, not normative, for W3C PR/REC purposes. W3C and WHATWG will collaborate on tooling to enhance the annotations.
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:
- 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;
- The Working Group shall escalate the disagreement to the WHATWG Steering Group to help resolve the issue;
- 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;
- 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;
- 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.
- If the Director overrules the objections, then W3C continues its process to publish the HTML or DOM Review Draft as a REC;
- 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 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, at least 3 months before the CR publication, and should be issued when major changes occur in a specification.
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
- 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 (APA) Working Group
- For accessibility horizontal review, and to collaborate on accessibility related topics.
- Internationalization Working Group
- For internationalization horizontal review, and to collaborate on internationalization related topics.
- Privacy Interest Group
- For privacy horizontal review, and to collaborate on privacy related topics.
- Technical Architecture Group (TAG)
- For architectural horizontal review, and to collaborate on architecture 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.
- Web Security Interest Group
- For security horizontal review, and to collaborate on security related topics.
To be successful, this Working Group is expected to have 4 or more active participants for its duration.
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.
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. Specifications will be developed on a public repository 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 firstname.lastname@example.org (archive).
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.
This Working Group operates under the W3C Patent Policy (Version of 5 February 2004 updated 1 August 2017). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations 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.
This Working Group will use the CC-BY license, and follow the terms of WHATWG-W3C Memorandum of Understanding.
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.
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|