A pragmatic guide to browser support

A pragmatic guide to browser support Rachel Andrew | Google Chrome | https://rachelandrew.co.uk

Baseline Clarifying the language around browser support for features.

A Baseline Newly available feature is supported in: • Chrome (desktop and Android) • Edge • Firefox (desktop and Android) • Safari (macOS and iOS) After 30 months the feature becomes Baseline Widely available.

Container Queries Baseline Widely available as of 14 August 2025.

Choose your own Baseline Adopt a Baseline year that makes sense for your audience.

https://chrome.dev/google-analytics-baseline-checker

Your Baseline Widely available or the Baseline year that you’ve decided to adopt. Everything past that line can be used without fallbacks or polyfills.

No Baseline doesn’t create a hard line, past which you can never go.

What’s the fallback? Some features make a straightforward progressive enhancement.

https://developer.chrome.com/blog/css-text-wrap-pretty

Feature queries in CSS Some features can have a fallback to another CSS method, with a few lines of extra CSS wrapped in @supports.

Is there a polyfill? The most frequently asked of questions when introducing a new feature.

The search for gold standard polyfills The perfect polyfill is hard to find.

A polyfill that we can recommend for all cases is unusual. Most have some caveats, or require an understanding of the environment. • You have understanding of your site and how the polyfill is used. • You can test to check for performance issues. • You understand the team maintaining the site and whether you are able to address any issues that might arise later due to the polyfill.

What’s the path to Baseline? How long will it take for people to have this feature?

Newly available features These features are already interoperable, they haven’t reached your Baseline yet.

https://web.dev/blog/at-property-baseline

Look into the future of browser support Baseline gives you a way to know “how long until I can use?”

https://web-platform-dx.github.io/web-features-explorer/features/subgrid

Single-browser implementations How to think about features that are only in one browser.

https://developer.mozilla.org/docs/Web/API/Background_Fetch_API

Single-browser implementations need to be carefully considered. Use them if: • You are happy with the fallback strategy. • You are able to watch out for changes to the feature as it progresses to more than one engine. Avoid these features when handing the site over to a client who might not have the ability to make updates.

Is the feature on a standards track? This means that it’s being developed within a standards organization—for example a CSS Working Group working draft.

https://wpt.fyi/interop-2026

Understand standards positions If a feature has a negative standards position from one browser, it’s unlikely they will implement it until something changes.

Missing in one browser So close! Not experimental, but also not Baseline.

https://webstatus.dev/features/contrast-color

https://webstatus.dev/stats

Two implementations more stability If two engines have implemented it’s far less likely the specification will change.

https://web-platform-dx.github.io/web-features-explorer/features/scheduler

Give browsers your use cases! Showing why you need a feature can help to get it prioritized.

Browser support We can’t get away from “it depends” but we can make decisions based on data and knowledge of our audience and constraints.

Define your Baseline Use your audience data to pick a Baseline year, or use Widely available as your Baseline.

Who will maintain the site in future? This can help you know how conservative you should be when it comes to experimental features or the use of polyfills.

Understand a feature’s path to Baseline Is it Newly available, implemented in two browsers, or a single browser implementation?

What’s the fallback? If you’ve decided to use a feature not in Baseline, what’s the experience for users who don’t have the feature.

What’s the future? If you use a polyfill, do you have a removal strategy when the feature becomes part of your Baseline? If using an experimental feature, how are you tracking potential changes to it?

Yes! Use Baseline and the data around it to feel more confident when using features that are not yet part of your Baseline.

Thank you https://noti.st/rachelandrew/osjHV8