A definition update for Baseline

At Google I/O this year we introduced Baseline, with the aim of creating a line in the sand indicating whether web platform features were ready for you to use. This post explains how the definition has evolved—with the help of the feedback we received from the community and the work of the WebDX Community Group.

What has changed?

The original definition of Baseline was that features become part of Baseline when they are supported in the current and previous version of all major browsers—Chrome, Edge, Firefox, and Safari.

In discussions with the community we learned that there were two noteworthy points in the lifecycle of a feature on the web platform:

  • The moment the feature becomes interoperable, available across all major engines.
  • The point at which most sites can safely implement that feature, without needing to worry about support.

The first of these stages is very simple to define, we know when a feature becomes available in all major engines. Here on web.dev we often celebrate these moments.

The second stage is much harder to define. Depending on the audience for a site or application you may be happy to start using features very soon after they become interoperable, or you may need to wait a period of years for enough of your users to have upgraded to browser versions that support these features.

To provide oversight for Baseline, the WebDX Community Group—which includes representatives from all major browser vendors—formed a governance group for the Web Features project. After much discussion from the whole group, the governance group redefined Baseline to reflect the two key points in the timeline of a feature.

  • Newly available: An item is newly available in Baseline when it becomes interoperable across the main browsers.
  • Widely available: The point at which the feature is generally safe to use. This line is set at 30 months after the newly available point.

We have also expanded the core browser set to explicitly include mobile versions of those browsers. This means that a feature won't be classed as newly available until it is available in:

  • Safari (macOS and iOS)
  • Firefox (Desktop and Android)
  • Chrome (Desktop and Android)
  • Edge (Desktop)

We know this widely available line can never be accurate for everyone. However, when looking into the available data on adoption of browser versions we learned that for most features it takes no more than 30 months for them to be available to about 95% of users globally. You may feel happy to use features much earlier than this, but it is unlikely that you will be unable to use a feature after this period of 30 months from interoperability.

Your own line in the sand may be between newly available and widely available. At the very least, the newly available point is an excellent signal that this feature is something you might want to start learning. That way you'll be ready to use it in production when it becomes more widely available.

What's next for Baseline?

To realize our goal to have the Baseline status displayed on MDN and other properties, we need to map all of the features of the web platform in the Web Features dataset. This work is still ongoing and we expect to be complete during 2024.

MDN has also announced this change to Baseline today. You can read the post about Baseline's evolution on MDN on the MDN blog, and see examples of the new Baseline badge being rolled out across MDN pages.

We also intend to start to implement a badge indicating Baseline status on web.dev and developer.chrome.com.

Find out more