How to Use Baseline Data

I’m one of the leads of the Baseline initiative that was started by a team at Google Chrome and is now defined by the Web DX Community Group. The idea behind Baseline is to make it easier for developers to understand what’s available to use across browsers in a web platform that is changing at a faster rate than ever before. In this post, I will answer the question I’m most often asked, “why doesn’t Baseline consider polyfills or progressive enhancement?” but also demonstrate how Baseline can make the decisions about using polyfills and progressive enhancement much easier.

A small group within Chrome thought about the idea that became Baseline for almost two years before an announcement was made. We spent a lot of time looking at research and what developers were actually doing and telling us. We tried to work out the best way to solve this constant issue of it being hard to understand when things on the platform were ready to use.

Initially, we considered a path that included polyfills. We thought it might be possible to have a less conservative version of Baseline that also included things with a solid polyfill. What became quickly apparent, however, was that very few features can be completely polyfilled so that you can just drop in the polyfill and use the feature as specified.

Take container queries, for example. It’s possible to write a polyfill for container queries, and in some cases, it will work without causing huge performance issues. You would be likely to hit problems, however, if it were used without careful consideration.

In addition, polyfills often only cover part of a feature, so to use them, you need to understand what is available. In almost all cases, the answer to the question of whether a polyfill was a good idea for a feature was “it depends.”

The aim of Baseline is to have a clear and objective line for support, so we didn’t pursue the idea of a line that included polyfills. That doesn’t mean we don’t think you should use them, but that the decision needs to be made with an understanding of your project, use case, and audience.

Several features are currently newly available that are very straightforward progressive enhancements, for example, text-wrap: balance. This is the sort of feature where if it isn’t available, nothing bad happens, but those users with the feature get a slightly better experience.

There are other features – subgrid, for example – that you could allow to fallback to a regular nested grid, thus losing some alignment but leaving things readable for everyone.

The problem with progressive enhancement is that the appetite different people and teams have for it varies. I’ve been telling people for well over twenty years that websites do not need to look the same in all browsers. There are many developers (or their bosses or clients) who very much disagree, even as we approach 2025. This means that any decision around what makes or does not make for good progressive enhancement is entirely subjective. As with polyfills, it also depends on where and how the feature is used.

Both polyfills and progressive enhancement involve decisions we can’t make with availability data.

This discrepancy means I might think it’s absolutely fine to use some feature even if it means some people don’t benefit, whereas your project requirements would mean it can’t be used.

Polyfills and progressive enhancement of newly available or limited availability features are probably best left to individual teams to make decisions on. Baseline, however, can still help you here.

For Baseline to work, we first had to understand the web platform as a set of features and then work out the status of those features. This feature grouping work has given us, for the first time, a view of the interoperability of the entire platform. This means we can see how many features are currently Baseline Newly available. At the time of writing, there were 139 features.

If you’ve decided to adopt Baseline Widely available as the point at which you’ll use features, you can feel free to use those features. You can then decide on a case-by-case basis whether to use Newly available features, and because you know exactly which features these are, it’s much easier to do that.

For example, you might want to use the new small, large, and dynamic viewport units. You can see that they've been Baseline Newly available since the end of December 2022. If you are just starting work on a brand new project next year, which you don’t intend to ship until the middle of the year, this feature will be widely available by then. This may give you confidence to use it.

Perhaps you’ll consider container queries, which won’t be Baseline Widely available until August 2025, but feel happy to take the approach explained by Philip Walton in How to use container queries now to offer support to those users with a browser that hasn’t caught up yet. Or you’ll cheerfully use text-wrap: balance, which won’t be Baseline Widely available until November 2026, acknowledging that it’s just a nice enhancement for those who have it.

What Baseline Newly available gives you is a defined group of features that you know you can use with a little extra care. You know they are interoperable, so they aren’t likely to change. You know that the vast majority of your audience will, in most cases, already have them. You know that as time passes, more of your audience gets the enhanced experience they bring. Importantly, you have a clear date when you can expect the feature to be available pretty much everywhere.

On the Web Platform Status dashboard, click the columns button and select Show Baseline status high date and Show Baseline status low date. The Baseline low date is when the feature becomes Newly available, and the Baseline High date is Widely available.

Creating the web features data set has been a huge project. As I write this, however, that work is over 80% complete, and the data is available in the npm web-features package.

I believe this dataset will open up so many possibilities for incorporating Baseline into our work. It should allow tooling to be created that helps you know which features you need to consider more carefully. If you could see the Baseline status of any feature in your editor, then you know when you need to make decisions about polyfills or fallback code. I think it would be useful to have a way of identifying things that have become Widely available since being used in a project, to make it easy to remove polyfills that were no longer useful.

We’re already starting to see the first experiments along these lines. For example, the bl2bl project turns Baseline thresholds into browserslist configurations. There are so many possibilities, and I’m excited to see what we and the community can create.

Rachel selected Feline Fine Foundation for an honorary donation of $50

This local charity helps keep cats and their owners together by providing crisis fostering when an owner is made homeless, goes into hospital, or escapes domestic abuse.