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.

Feel free to chime in with more of your own so this can be as helpful of a resource as it can be!

HTML Features

View Transitions

// Not Supported
if (!document.startViewTransition) {
  updateTheDOMSomehow();
} else {
  // Supported
  document.startViewTransition(() => {
    updateTheDOMSomehow()
  });
}

I’m really not sure how to test for @view-transition support.

Popovers

// Supported
if (HTMLElement.prototype.hasOwnProperty("popover")) {

}

<dialog> Element

// Supported
if (typeof HTMLDialogElement === 'function') {
 
}

Declarative Shadow DOM

// Supported
if (!!Element.prototype.attachShadow) {

}

Lazy Loading Images

// Supported
if ('loading' in HTMLImageElement.prototype) {

}

Lazy Loading Iframes

// Supported
if ('loading' in HTMLIFrameElement.prototype) {

}

CSS Features

CSS selectors and property: value pairs can be tested with CSS.supports() from JavaScript.

:where()

// Supported
if (CSS.supports('selector(:where(h1))')) {
  document.documentElement.classList.add("supports-where");
}

:has()

// Supported
if (CSS.supports('selector(:has(h1))')) {
  document.documentElement.classList.add("supports-has");
}

@layer

// Supported
if (typeof CSSLayerBlockRule !== "undefined") {

}

Anchor Positioning

// Supported
if (CSS.supports("anchor-name: --anchor-el")) {

}

Subgrid

// Supported
if (CSS.supports("grid-template-columns", "subgrid")) {
  
}

light-dark()

// Supported
if (CSS.supports('color: light-dark(black, white)')) {

}

OKLCH Color

// Supported
if (CSS.supports("color: oklch(0% 0 0")) {

}

JavaScript Features

AbortController

// Supported
if (typeof AbortController === "function") {

}

Promise.finally()

// Supported
if (typeof Promise.prototype.finally === 'function') {
  
}

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.