Getting Wide Review
To help the API owners follow the guidelines for Web Platform changes, every intent to ship has to show what external stakeholders (in particular the W3C TAG, the non-Chromium browser engines, and web developers) think about the new feature. These signals are only a few inputs that the process takes into consideration. None of them are either a veto nor an implicit approval to ship.
This page describes how to collect that evidence. See the launch process when to request reviews.
Exceptions
Some changes are too small and non-controversial to justify the effort of TAG review or requesting standards positions. Whether a feature is in this category is up to the discretion of the API owners during their approval of an intent to ship. You can ask ahead of time via blink-api-owners-discuss@chromium.org. Mark these as "Not applicable" and "No signals".
Consensus features in certain working groups don't need either TAG reviews or standards positions from other browser engines:
- ECMAScript features at stage 3 or higher.
- WebAssembly features at phase 4 or higher.
- Khronos features developed under its Working Group Guidelines, for which the specification has been committed to the relevant Khronos standard & reflected on the Khronos website. (documentation)
Other features don't need to request a TAG review but still need to request standards positions:
- The intent ships a new API or augmentation of an API, or changing an API to
match a spec, that is
- already specified and accepted by the relevant standardization body, and
- has already shipped in at least one other browser.
- The intent removes a feature or part of a feature.
- The intent is for WebDriver / WebDriver BiDi support for a feature already shipped in Chromium.
TAG review
The W3C TAG is most effective when it can suggest changes early in a feature's design. To get this input at the right time, try to request an "early design review" when you have a solid description of the problem you're trying to solve, a collection of alternative solutions, and one solution prototyped to demonstrate that it's viable. This is likely around when you start developer trials.
When you have a complete specification for your feature, you should give the TAG another opportunity to review it, unless they said not to in the early design review. If they didn't close the early design review, or if your final specification does not differ in any significant way from the the form reviewed by the TAG, just comment on the early design review saying that a specification is ready. No need to reopen the issue in that case. Otherwise (the early design review is closed and the design has changed in any significant way), open a new "specification review".
The TAG sometimes leaves a review open for several months, during which the relevant stakeholders find consensus or Chromium ships the feature. If that happens, it's best to notify the TAG so that they can close the issue and prioritize other issues. If Chromium ships without wide consensus, it's still polite to inform the TAG that Chromium considers the feature stable, and future proposals for changes will be weighed against the compatibility risk of changing a shipping feature.
Browser engine standards positions
Request formal standards positions from the Gecko and WebKit browser engines around when a specification goes to Origin Trial or when you believe the feature is in close to its final form, at least a month before you plan to send your intent to ship.
For cases where the signal is not Shipping/Shipped or In Development, the Official Standards Signal Process (see next section) for that implementation should be followed to obtain a signal. If the Official Standards Signal Process is skipped or incomplete and N/A or No Signal is reported, it should be reported why. Reasons why can include:
- The feature has an exception.
- The Official Standards Signal Process was followed but no response came in a reasonable timeframe
For each of Gecko and WebKit, state one of the following signals:
| Signal | Required evidence |
|---|---|
| No Signal | Link to Official Standards Signal Process issue or thread that is not yet complete |
| Shipped/Shipping | Link to public documentation or bug/issue that demonstrates the issue has shipped (i.e., an issue that links to patches that have been merged, or a comment that a previously disabled feature is now enabled by default). |
| In Development | Link to public documentation or bug/issue clearly indicating feature is in development (not just filed as a bug or under consideration). When in doubt, follow the Official Standards Signal Process |
| Positive | Statement made through an Official Standards Signal Process for that implementation |
| Neutral | Statement made through an Official Standards Signal Process for that implementation |
| Negative | Statement made through an Official Standards Signal Process for that implementation |
| Defer | Statement made through an Official Standards Signal Process for that implementation |
| N/A | Indication of why an Official Standards Signal is not needed in this case |
Official Standards Signal Process
Gecko
File a Mozilla standards position issue. The possible outcomes of this are: positive, neutral, negative, defer, and under consideration. Link to the issue in the Implementation Signals List.
WebKit
File a WebKit standards position issue, and link to the issue in the Implementation Signals List. The possible outcomes of this are:
- support ⇒ Positive
- neutral ⇒ Neutral
- oppose ⇒ Negative
- not considering ⇒ No Signals
- blocked ⇒ No Signals
- duplicate ⇒ usually use the URL and signal of whatever position this is a duplicate of
- invalid ⇒ If you don't understand why the position is "invalid", ask your spec-mentor for help.