The WHATWG develops standards and assists in maintaining their corresponding tests, thereby fostering independent implementations. The WHATWG adheres to a shared Code of Conduct.
While discussing and working on standards, it’s always useful to keep these questions in mind:
Each standard (ideally) has:
The editor has the following responsibilities, all of which can be delegated to deputy editors:
Problems with the standard are generally recorded as issues. Resolving an issue typically involves answering these questions:
It’s not always possible to get the answers to all these questions in a timely manner. Therefore, it might be the case that a decision is made even without input from all parties. This makes it very important to file bugs for any spec changes (as discussed below), as a final check to make sure all implementers are on board with, or at least aware of, the change.
Additions to the standard can also be proposed as issues. However, the process for turning such an issue into an accepted change to the standard is generally more involved, as the criteria for additions is stricter (see Additions). A typical path for turning such issues into accepted changes is detailed in the New Proposals section.
Changes of editorial nature, or which only impact non-normative text, can be made, accepted, or rejected by the editor without discussion.
The same applies for changes which are (in the editor's judgement) obvious bug fixes, where the standard failed to reflect the clearly-intended behavior in its normative text.
Some representative cases of such "obvious bug fixes" are restoring an accidentally-deleted step, correcting a value to match the declared IDL type signature, or passing a value through the algorithms that expect it.
if implementations disagree on a behavior, then even if the correct fix feels obvious, it's better to start a wider discussion and take the fix through the normative change process.
Each normative change made to the standard needs to meet the following criteria:
Additionally, the following more mechanical criteria are used to hone a change before accepting it:
If the change is proposed by a new contributor, the editor can ensure the commit message is good, and help with formatting and style. There’s no need to make new contributors jump through too many hoops.
Any change that represents an addition needs to meet these additional criteria:
Additionally, the following are strongly recommended:
Any change that represents a removal needs to meet these additional criteria:
The feature being removed must either be not widely implemented, or must in the process of being removed from implementations.
A test ensuring the feature is not supported must be added and existing tests for the feature should be adjusted or removed as appropriate.
w3c/web-platform-tests#5001 added new tests that appcache was not supported in shared workers, per the removal in whatwg/html#2384.
Adjusting existing tests can be difficult. If necessary, an issue can be filed instead to track updating those tests. This was done in w3c/web-platform-tests#5053 which accompanied the removal in whatwg/html#2402.
As described above, the criteria for inclusion in a WHATWG standard is rather strict. In the initial stages of feature development for the web platform, such widespread implementer support is often not available, or the shape of a feature is not yet clear enough for implementers to feel comfortable pledging their support.
In such scenarios we anticipate features will be “incubated” outside of WHATWG standards. This could be in a variety of venues, such as:
Another standards organization
A personal document or GitHub repository
A pull request to a WHATWG standard, with the understanding it will not be merged until the criteria above are met
A document hosted by the WHATWG, but not under the spec.whatwg.org subdomain and not titled “Living Standard”
The CanvasColorSpace proposal is being incubated on the WHATWG Wiki.
In all cases, features that hope to graduate to a WHATWG standard should strive to follow the above guidelines, gather appropriate implementer commitments, and have corresponding tests.
Additionally, those maintaining such proposals should try to involve the WHATWG community, for example by filing an issue on the standard they anticipate eventually becoming a part of. We also have the optional Stages process to help gather attention on proposals as they progress.
Overall, this process of incubation can be very lightweight, such as filing a pull request on the appropriate WHATWG standard with a proposal, and gathering appropriate implementer support there. Or it could be more involved, such as creating a separate repository at another venue and iterating for a long time there.
The addition of URL.prototype.toJSON() was rather straightforward once a plan was agreed upon and upstream IDL issues were resolved: whatwg/url#137.
innerText was initially drafted in a repository outside the HTML Standard. Integration into HTML then went rather smoothly: whatwg/html#1678.
As discussed in Changes, normative changes to a WHATWG standard requires tests, usually submitted to web-platform-tests. At a high level, these tests should strive to:
In case of a conflict among the community of contributors, the editor is expected to go to significant length to resolve disagreements. In the end, they make a judgment call to pick the best option they believe will have multi-implementer support.
If a workstream participant believes the editor's choice will not have multi-implementer support, and they cannot convince the editor, then they may formally appeal to the Steering Group. In their capacity as implementers, the Steering Group may correct or uphold the editor's decision.
Implementations can always override the editor by implementing something else. Whenever that happens a breakdown in communication has taken place that the community should seek to overcome and find ways to prevent it from happening again.
Implementations that disagree can be rather tricky to sort out. Generally, we try to approach these situations as follows:
A standard is a tool towards convergence, and changing a standard can often be a pragmatic solution in case of conflict.
Implementation disagreement should not result in implementation-defined behavior or optional features.
Most Workstreams don't run any regular meetings. However, as circumstances arise, meetings can be helpful to resolve difficult issues, or to liaise with other groups.
There is a regular triage meeting held approximately every other week to unblock issues across all WHATWG Workstreams. Topics may come from any WHATWG repository; you can find the information on the next meeting by looking for the upcoming WHATNOT meeting in the HTML standard repository. Topics are added to the agenda for the next meeting by adding the "agenda+" label in any WHATWG standard repository. The timing of this meeting changes to distribute across time zones. We may also hold similar triage meetings in-person alongside other industry events; we did so in 2023 as the WHATUP meeting.
Announcements or requests for meetings are to be filed as issues against the relevant Living Standard repository. To allow maximum participation in a meeting, meetings should be announced early and provide an option for remote participation if possible. Transcripts, minutes, or recordings of a meeting should be made available shortly after the meeting concludes (linking from the original meeting request issue is a good way to do this).
Any decisions made during in-person meetings are to be considered non-binding (tentative and subject to appeal from those not present).
Often other standards want to reference parts of a WHATWG Living Standard by using a hypertext anchor. Since Living Standards are continually evolving, the set of anchors in a document is not static, and some anchors could disappear over time.
In general, editors should try to preserve anchors when reasonable. This includes using techniques like:
The console object changed from being a Web IDL interface to a Web IDL namespace. Although the Console Standard's new anchor is #console-namespace, the old anchor of #console-interface still works.
Although the concept of "structured cloning" has been replaced by structured serialization, the HTML Standard's #structured-clone anchor points to a note explaining this evolution, so that old links do not break.
Consumers who need to reference exactly what a Living Standard said at a given point in time, for example to document what they implemented from or to explain the history of the web platform, can use the commit snapshots functionality. Each Living Standard has a "Snapshot as of this commit" link that gives a frozen copy for such historical reference. The WHATWG will keep these snapshots available at their published URLs permanently. However, other standards organizations are discouraged from referencing these snapshots, as they generally contain contain known issues that have been fixed in the Living Standard, and can mislead implementers and web developers.
For cases where another standards organization wishes to ensure an anchor is permanently available in the canonical Living Standard, they may file a new issue requesting a permanent anchor and detailing the anchor(s) they would like preserved. See all current and past requests for anchor permanence. The editor can then discuss this request with the requestor; for example, if the editor was planning on making changes in the near future, maybe they would advise the requestor to hold off on linking to that anchor until the changes go through.
After discussion concludes, such requested anchors get promoted to be permanent. This means that it becomes a matter of WHATWG Policy to never break them without the requestor's assent. (This is enforced via technical means in the specification tooling.) If an editor has a strong reason for breaking the anchor in the future, they should reach out on the original issue thread to the requestor to discuss how to proceed. This may result in breaking the anchor with the requestor's assent, e.g., because the requestor is prepared to update their referring standard. Otherwise the anchor will have to be maintained in the standard in some manner.