So here’s Browserslist¹.

Browserslist is the developer community at it’s best. There are a bunch of tools that make choices about what they do based on what browsers they are trying to support. Like the intro on their homepage says:

Shared browser compatibility config for popular JavaScript tools like Autoprefixer / PostCSS, Babel, ESLint, and Webpack

Links to those tools added by me, linking to their Browserslist details. LightningCSS is another one.

So instead of all these tools coming up with their own syntax for how to express a set of supported browsers, they all use this shared syntax. And not even just a shared syntax, they can even share the same location or file (i.e. .browserslist) to store that information.

That’s great. It’s in the same vein as the famed package.json file being the canonical source of packages and JavaScript processing information, or .editorconfig for all editor behavior and prettification needs.

Browserslist recommends "defaults" if “you’re building a web application for the global audience.” This translates to their config "> 0.5%, last 2 versions, Firefox ESR, not dead". That translates to any browser which has more than half a percent of browser share (it gets browser data like this), the last two major versions of all major browsers, Firefox “Extended Support Release” specifically, and only “not dead” browsers (as in, not Internet Explorer).

That’s pretty reasonable? But you can always add things to your support list if you need to go deeper or be more specific.

But now Google is in the game of qualifiying web platform features with Baseline.

Web Platform Baseline brings clarity to information about browser support for web platform features.

Their biggest rubber stamps are “widely available” and “newly available”.

• Baseline Widely available includes all web features that were fully supported by the Baseline core browser set 30 or more months in the past.
• Baseline year feature sets, for example Baseline 2020, include all features that were Newly available at the end of the specified year.

This means you can literally use Browserslist config strings to use these delegations.

"baseline newly available"
"baseline widely available"
"baseline 2022"

Specifying a year, like the last example above, might be how your project wants to roll! I don’t hate it, honestly. If I were to use "baseline 2020" as config and run CSS through Lightning CSS, I’d see some transformations like this:

If we went back to "baseline 2018" we’d even see some big transformations of padding-inline-start transformed into padding-left for a big ol’ pile of :lang() values and padding-right for another big pile (!!).

If we went forward to "baseline 2022" we’d see the color() declaration go away, leaving only the #hex and lab() values left, but the rest would be the same.

I think the general “recommendation” (if that’s fair) is to use "baseline widely available" where our CSS transformations are like this:

Using "baseline newly available" is still somewhat cross-browser compatible, just not to the level of widely available. To be “widely” available the feature needs to be baseline for 30 months! So I’d say pretty-darn available. Using "baseline newly available" we get:

Example Repo

I tossed together a repo for testing this stuff. You can basically change the config here. It’s an npm run dev thing and it’s wired up to not fingerprint or minify, so it’s easy to see both src and dist files like the screenshots I was doing above.

It’s also wired up to do JavaScript processing with Babel, although I’m not 100% sure I even did that part right, but if you wanted to test JavaScript transformation on this stuff, it might be a good starting point.

Stuff That Isn’t Touched

Remember that CSS features aren’t always transformable to backwards-compatible things. Like if you use @layer or rlh units or something, that’s just going to get left alone despite any browser support levels. Same with stuff like shape(), which is brand new, and would be awesome if they ported it to something, but alas, they do not.

Final Thoughts

I think it comes down to a battle: "defaults" vs. "baseline widely available". Anything else is just playing around or very specialty situations. Between the two, I think I’d actually go with "baseline widely available". It just seems a smidge more modern and I like the momentum behind it.

The best possible move is to use your own analytics data to inform the choices. This can be done with a Baseline Target Report and Jeremy Wagner and Rachel Andrew get into it in How to choose your Baseline target.

1. The pluralization of Browserslist is weird. Feels like it should be Browserlist. You’ll also see config strings like “last 2 version” which then lacks the pluralization it wants (but it also works pluralized). 🤷‍♀️ ↩︎

One of my historical criticisms is that a view of browser support this simplistic might push people away from using a feature when they need not be.

As I write, Safari only just released both forms of support and Firefox remains without support for the View Transition API.

But who cares? Using these features has little negative impact on non-supporting browsers (assuming you do the very little it takes to not have JavaScript throw on an un-supported function call). The View Transition API is quite progressive enhancement friendly.

I also understand that one widget can’t be the entire answer for educating the world on web platform features and when it is appropriate to use them. Entire blog posts can struggle with that.

So I appreciate Rachel Andrews chiming in on this specifically:

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.

I disagree with their disagreement! lolz. Progressive enhancement doesn’t hurt anyone, it lets you use features when ready to do so, so being against that as a concept doesn’t work for me.

I think I would like to see something like “🌟 Progressive Enhancement friendly!” in the widget somehow.

The story is similar with polyfills. The Baseline widget doesn’t ever say “it’s not supported, but there is a polyfill you could use!”, which is something that might be very important information to have when deciding to use a feature. Again Rachel has insight:

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.

In this case, I think I agree with the decision not to include any information about polyfills. In my experience there are precious few truly good polyfills, they do have a potential negative user impact, and they are a moving target.

I super appreciate the inside look into how decisions like these are come to!

What we need now is some UI somewhere that helps us figure out what the heck value to use as the featureId="" in the <baseline-status> component.

What I tend to do is go for what I feel like the biggest highlights, as well as stick to the Big Three: Chrome, Firefox, and Safari. Saying “this only works in Safari right now” is pretty important information to know, or, “this works in Chrome and Firefox and we’re waiting for Safari support.”

That may be a bit simplistic. I’m aware Edge exists, for the record, it just uses Chromium so it doesn’t feel particularly notable to call that out. Same story with browsers like Opera, Samsung Internet, and Arc: it’s just Chrome. If there really was a big important difference between Regular Chrome and Samsung Internet or whatever, I’d call it out, it just seems awfully rare. I typically just say “Chrome ‘n’ Friends”.

I mostly find Safari and Safari iOS not terribly different either, but if there was a serious difference it would definitely be worth calling out.

I also like to link to a source that is known to update. That typically means whatever the relevant MDN page is or caniuse, which is more and more MDN powered anyway.

I’ve been talking about scroll-driven animations a bunch, so linking to a highly relevant property like animation-timeline on caniuse I feel like is a pertinent thing to do, while also saying something like:

At the time of this writing, scroll-driven animations are only a Chrome ‘n’ Friends feature, but I see feature flags in both Safari and Firefox so it’s coming!

That caniuse page pulls data directly from MDN anyway, so a link directly to the browser support for that property is probably even better. That’s what hash links are for I suppose.

What to Avoid

Screenshots of browser support tables. It’s just going to go out of date, probably faster than you think.

Live Updating Embeds

Ire Aderinokun’s CanIUse Embed takes this job on. It sucks the data in from caniuse (or MDN) then produces an iframe of that feature. Here’s what it produces for the text-decoration-skip-ink feature:

Data on support for the animation timeline feature across the major browsers

That’s pretty neat, but…

The CanIUse Embed is probably worth avoiding for now

While it’s still mostly functional, I think the page has fallen just enough out of date that it’s best to avoid using.

• The “Select Feature” dropdown doesn’t have much by way of new features. Nothing I was trying to use it for was there: scroll-driven animations, anchor positioning, etc.
• The data seems weirdly wrong. Try the CSS selector :has() — it lists no support in any browser. That text-decoration-skip-ink chart above? That’s also kinda wrong. The MDN chart is much more nuanced, listing support by sub-feature, and accurate.
• It gives you invalid HTML, with nested <p> tags.
• It doesn’t link out to a useful canonical source for the specific data.

It’s a cool idea and it could be fixed up, but it’s pretty busted for right now.

Using Baseline

Google has been working on Baseline for years now. It’s a bit of a simplified version of understanding browser support. They’ve just recently released a web component for displaying the Baseline widget wherever.

Here is their example usage:

<script src="https://cdn.jsdelivr.net/npm/baseline-status@1.0.4/baseline-status.min.js" type="module"></script>

<baseline-status featureId="anchor-positioning"></baseline-status>

It requires you know what the featureId is for whatever you want to embed, and it looks like the place to find that information is this folder on GitHub.

So it’s useful, compact, and up-to-date, it’s also limited to what they’ve got data on at the moment, which ain’t everything. I couldn’t find the animation-timeline I’ve been using as an example, for instance.

What I’d Like to See

Browser support is nuanced, but just a little. If you see a big ❌ next to a scroll-driven animations or view transitions feature, you could be put off it and become sour to the idea of learning about new features too soon. But those features are easily progressive enhancement territory. It doesn’t mean don’t use it in the same way, say, something like file browser APIs, which directly affect certain apps core experience.

When a feature isn’t supported in a browser, I feel it’s very pertinent information to say:

• Not supported, but it’s polyfillable!
• Not supported, but it’s basic progressive enhancement territory!

I’d love it if these browser support charts/widgets could be more clear about that.

The “When”

Rachel Andrew:

There’s a good number of developers who love to hear about new things landing on the platform. However there’s a much larger group of people who really just want to do their jobs, and who can’t invest time learning new things until they can use the new things. If we publish all of our material when things are experimental or only available in a single browser, all the noise happens at the wrong time. This leads to people missing the fact that things have become available everywhere. So, don’t forget to write about the Newly and Widely available things, you’ll be speaking to a much bigger audience, and providing people with something they can use in their production sites right away.

I feel like that’s good advice for this very website. There is plenty to talk about on the web without so much focus on the very newest and most experimental.

The idea is for it to accompany a web platform feature so you can have a sense of what browsers support it. Web developers are rightfully skeptical of new web tech, wanting to know when they can actually use a feature, so this is helpful.

But there is crucial information missing here. Developers don’t decide to use a feature only based on browser support, but also:

1. Based on if that feature could be considered a progressive enhancement
2. Based on if that feature has a polyfill

Jeremy Keith brought this up and has a great point.

Not all browser features work the same way. For features that work as progressive enhancements you don’t need to wait for them to be widely available.

For example, if you’re looking at the View Transitions API, you’ll see:

And perhaps go awww bummer I can’t use it! But that would be wrong. You can use it. The API is designed such that you can write code that will use it if it’s available or not if it’s not. It’s really not a big deal.

That’s a beautiful part of progressive enhancement, as Jeremy says:

… there’s a real irony in a common misunderstanding around progressive enhancement: some people seem to think it’s about not being able to use advanced browser features. In reality it’s the opposite. Progressive enhancement allows you to use advanced browser features even before they’re widely supported.

I’m a little confused by it. It could just be me. I suppose I’m looking either to be enlightened, or to offer this as feedback in case others share my confusion.

Baseline looks like this:

ERRRR wait. No. That’s not baseline, that’s just a browser support widget thingy. I think it’s kinda conveying the same information, only better because it has more detail than Baseline, but I think this is actual the Baseline widget:

This UI widget is fairly new, and it’s used in a variety of places:

• Google’s own sites, like web.dev, developer.chrome.com etc.
• MDN
• caniuse

It’s neat that it has been adopted across several important web developer-focused sites.

As best I can tell, Baseline is only shown by web platform features which meet the baseline, that is, are decently well-supported. You’ll never see a Baseline widget with big red ❌’s on it saying the feature isn’t supported. Do I have that right?

The Root of My Confusion

So, as a developer hopping around developer documentation sites, I know:

• If I 👁️ see the Baseline widget, I can go “Cool! This feature is pretty well supported. I’ll look at the details, but I can probably use this.”
• If I 🚫👁️ don’t see the Baseline widget, I can go “Uh oh! This feature isn’t very well supported, it doesn’t meet the baseline. I probably can’t use this”

Except… I’m really just kidding about that second point. This widget hasn’t rolled out absolutely everywhere. It’s not even particularly easy to find examples of when specifically looking on sites that have it. Which is fine, I get that big initiatives take time to roll out.

So we’ll never be able to say: “I don’t see a Baseline widget, this feature isn’t well supported”. We’ll just be in the same position we are now: “I’ll have to go research the browser support for this on my own.”

The end result is that if we see the Baseline widget, we can get stoked. It’s a Badge of Ready to Use. Do I have that right? If I do, I feel like that’s… OK… but could be better.

Opinions

I remember Andrew Walpole once saying something like I just need to know which of these things is true:

• I can use the feature
• I can use the feature, because it has a polyfill.
• I can’t use the feature.

I think Baseline would be more useful if it was included near any Web Platform feature and said which one of those things applies. It’s such a little widget! I should go everywhere.

The little browser support chart Google already uses is closer to that, listing the earliest version a feature is supported in (or that it isn’t!) and a link to a source for more detail.

Maybe some kind of hybrid is warranted. Maybe the browser detail isn’t as needed if the support is deep across the board, and only is shown in non-support situations. I wouldn’t want to advocate for too much complexity, as there is value in the simplicity of Baseline, but it doesn’t even get into mobile browsers which seem pretty relevant to web developers. Not to mention the browsers I need to support might be different than the browsers you need to support and a widget probably will never be able to address that (hence the need to link out for detail).

They did just recently update the definition of Baseline (saying when a feature is “newly available” vs “widely available”), so there is dedication to simplicity here trying to be balanced with at least some level of nuance.