Add Baseline definition document

[ddbeck]

On Tuesday, November 7, 2023, the web-features governance team agreed to a new definition of Baseline, incorporating feedback from web developers, WebDX community group participants, and commenters on the web-features repository (mostly summarized by #374).

What’s the TL;DR?

Features are marked as interoperable from the day the last browser implements the feature; 30 months later, the feature is marked as having wider support.

What does the definition say?

To summarize, the definition says…

• Each feature gets a status describing the extent of support, from the moment of interoperability through the era of wider support.
• A feature gets an interoperable status on the day that the last browser in Baseline’s browser set ships the feature (i.e., on the “keystone date” or “interop moment”).
• A feature gets a wider support status after 30 months of interoperability or for the duration of LTS support releases at the time of release (though, in practice, 30 months is always longer).
• The governance team may override the Baseline status (e.g., to hold a feature back), recognizing the possibility of errors or misleading data and a method for correcting them.

How does this definition differ from the May 2023 definition?

If you saw the original definition, then the biggest changes are:

• Baseline recognizes browsers as supporting a feature as soon as it has shipped in the latest stable version. It no longer waits for two major releases.
• Baseline now notes interoperability duration, rather than the number of releases, as the main distinguishing factor for wider availability.
• Baseline now provides a keystone date to support a frequent request, versioning features by date.
• Baseline’s browser set was explicitly expanded to include mobile browsers.

It’s not part of the definition, but the governance team also approved a change to the project governance document: scheduling an annual review (and, if applicable, revision) of the Baseline definition.

What doesn’t the definition say?

The definition only provides directions for producing data: a low/high status value and a date.

That is, it marks the boundary on what features do or do not have a Baseline status. It does not prescribe developer-facing text, iconography, colors, or other display guidance.

The governance team expects that assets and display guidance will be incorporated into the web-features project after consumers of the Baseline data, such as MDN and Can I Use…?, have had an opportunity to experiment with presentation.

The definition does not cover any other conditions of interest (e.g., deprecated features, “shipping soon” features, or “feedback wanted” features). These are likely follow-up tasks.

What happened to the proposal to include <browser>?

The governance team did not reach a decision on other browsers or a formalized browser selection method.

The governance team selected the browser list in response to several factors, primarily reported developer interest (see https://github.com/web-platform-dx/developer-research/blob/main/vendor-research/browser-support-matrix-survey.pdf).

The governance team considered expanding the browser set further, to include other browsers tracked by mdn/browser-compat-data (BCD), MDN Web Docs browser compatibility tables, or Web Platform Tests (WPT). Going down that route might have added Samsung Internet, Opera, and mobile web views. These proposals faced questions about data quality, BCD’s deliberations over changing their browser set, and developer interest, which have yet to be answered. This is likely to be considered in more detail in the future.

[foolip]

Not filing issues for these, leaving them here seems fine to me.

[tidoust]

I understand that the list is not meant to be exhaustive, but I'm thinking it would still be useful to mention WebViews explicitly here - or perhaps in the Future Considerations section?. WebViews are also a widely used non-web web setting (and the term should speak to developers even though it remains ill-defined...)

[ddbeck]

Ah, this is a good thought though I don't know exactly where it sits either. I think it's more of a future consideration than a non-goal, but it's possible it could become a non-goal. I filed #477 to take up this question.

[tidoust]

I may be reading too much into this, but that seems to suggest that the revision is scoped to re-evaluating the duration, and only the duration, whereas my understanding is that the governance group will review the whole definition.

Suggested change

	This duration is due for review by the governance group on 7 November 2024.
	This duration (and the whole Baseline definition) is due for review by the governance group on 7 November 2024.

Alternatively, the ownership and maintenance section could perhaps make explicit the "revision at least once per year" policy.

[ddbeck]

Yes, I think this is probably worth moving or revising. That said, this was one of the late additions to the Baseline definition text. I'm not comfortable approving this unilaterally. I'd like to merge the text as is, then propose the narrower change here as a separate PR for the owners group to consider in isolation.