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 can be made, accepted, or rejected by the editor without discussion.
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.
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”
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.
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:
innerText was initially drafted in a
repository outside the HTML Standard.
Integration into HTML then went rather smoothly:
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.