Rethinking Browser Support with Baseline
Browser support policies often harken back to bygone days when Internet Explorer dominated the market. At Cast Iron, we recently used the Baseline initiative to update our own policy for an era of fast release cycles and widespread interoperability.
When Clearleft last year published a browser support policy based on the Baseline initiative, we, like others, realized it was time to revisit our own.
For years, Cast Iron had defined its policy based on browser versions, a longtime industry practice but an artifact of a time when browsers were released infrequently, and which version of Internet Explorer we supported was essential information for clients and developers alike. Up until it reached end-of-life in 2022, Internet Explorer anchored our support policy: whatever it could handle was the set of web features we could use.
In the ensuing years, we continued to use a support policy based around major browser versions—last two for Chrome, Firefox, and Safari—even when in practice this made little sense. Browsers these day update frequently. New major versions of Chrome and Firefox come out every few weeks. Safari updates less often—major versions are still tied to OS releases—but minor versions do come out regularly. What does it mean to support the last two versions of Firefox when Firefox will go through half a dozen major versions over the course of a client project?
Those who fund and work on browser development also invest much more in interoperability than they once did. While a new web platform feature may be in only one browser initially, and rarely one browser may never signal support, by and large features are reaching interoperability within months of initial support. Just look at the success of Interop 2024! This is a sea change from the heyday of Internet Explorer, yet the scars of having to navigate so much variability between browsers still leads us to think about support mainly in terms of browsers and versions instead of features themselves.
Untethered from Internet Explorer, working only with browsers that update frequently and offer widespread interoperability, is there a better way to frame a support policy nowadays?
About Baseline
Baseline is a joint initiative between Google, Microsoft, Apple, and Mozilla (and owned by the WebDX Community Group is an open forum to facilitate coordinated approaches to improve the overall experience of developing for the Web platform.) to provide clear information to developers about cross-browser feature availability. This initiative emerged from community discussions with developers in the period after Internet Explorer's sunsetting, with the intent to help reframe support policies in a sensible way for modern browsers.
Baseline focuses not on browsers directly but on interoperability, organizing web features into two categories:
- Newly available: a feature is in the latest version of all Baseline defines its "core browser set" as Chrome (desktop and Android), Edge, Firefox (desktop and Android), and Safari (macOS and iOS).
- Widely available: a feature has been in all major browsers for at least 30 months.
The idea behind the definition of “widely available” is that 2.5 years is a long enough duration to reasonably expect a given feature to fan out across primary and downstream browsers and through updates to reach almost all users. It is inevitably somewhat arbitrary, and may exclude some users. iPads, for instance, tend to be replaced much less frequently than other devices and thus are more likely to get stuck on older versions of Safari due to OS update limitations.
But strong interoperability and the common use of automatic updates means that the vast majority of users should have the feature in that timeframe, oftentimes much sooner.
Using Baseline for Support Policies
Like Clearleft, Cast Iron Coding last year decided to adopt the “widely available” category as a baseline metric for support. This is notably more conservative than our previous stated policy. 30 months ago, Chrome was at 106. Firefox was 104. And Safari was 16. That’s 30, 34, and 3 versions behind, respectively.
That is not to say that we don’t support any web platform features classified as “newly available”. Like Clearleft, we believe that core content and functionality should depend on widely available features, but that newly available features can be used with progressive enhancement.
Take Container Queries, for instance. CSS Containers make possible a number of powerful techniques for layout: units that respond to container size, queries to restyle descendants based on container size (and eventually, scroll state and style). The @container at-rule will become widely available in July 2025. But by providing a media query or other reasonable default for the context, and enhancing with a container query in a @supports block, we can begin using container-related features now.
So long as users who do not have these features available have a comparable, fully-functional, and still high-quality experience, we can absolutely embrace newly available and even emerging browser features. This is the web, after all, where differences between user experiences are a feature, not a bug.
The Benefits of Adopting Baseline
As we see it, the benefit of adopting Baseline as the foundation of our browser support policy is threefold.
Features, not Browser Numbers
First, it ties our stated policy directly to features rather than indirectly through browser numbers.
For developers, dealing with support has long been feature-based. We look up caniuse data to see what kind of support a feature has before using it. When we do use more recent features, we test for support in code first, always checking for availability of the feature, not what browser someone is using.
By adopting Baseline definitions, we can cut out thinking about browser versions and just look for the “widely available” indicator. MDN already displays Baseline information at the top of any HTML, CSS, and JavaScript reference page.
caniuse also indicates Baseline availability alongside its usual display of browser support info. The Baseline homepage lists many more online resources that have incorporated this information.
A Shared Language Between Stakeholders
Second, Baseline creates a clear, common language between stakeholders for how we define and practice browser support. If something has been in all browsers for at least 30 months, we’ll use it. And if not, then we’ll only use it as an enhancement over the core user experience. That is much easier for clients to understand, and much more straightforward for developers to practice, than the rapidly moving target of the last two versions of major browsers.
A challenge of our previous policy was trying to employ it sanely and consistently in our work. In the day-to-day, developers had to make judgment calls about when to use newer web features. If x feature is in Chrome and Firefox but only the latest version of Safari, is that close enough? What about if this project isn’t launching for a few months? Even following our “last two major versions” policy strictly, we were likely to implement features that may not be available to many users, and for core functionality as well.
Moreover, our Browserslist A Browserslist config signals to other tools what web platform features your project is meant to work with. Tools like webpack, Babel, and PostCSS use that information to determine when and where in your codebase to inject polyfills and other code to expand operability. This config is commonly defined in a project’s package.json file. was set to defaults, shorthand for > 0.5%, last 2 versions, Firefox ESR, not dead. That is, we supported the last two versions of living browsers as well as Firefox’s latest Extended Support Release and any other version whose global usage is greater than 0.5%. That’s much broader than just last 2 versions. This wasn’t a bad thing in and of itself, but it wasn’t consistent.
As a maintainer of the Baseline project writes, Baseline is above all else a communication tool:
[S]ince it appears on MDN, caniuse, and elsewhere, Baseline can offer something that a more precise "X% of users" can't: a shared terminology for coordination. "X% of users" encompasses lots of nuance and context: which users, how you measure them, what you think of users you can't or won't track, the browser releases that number translates to, and so on. [E]ven if Baseline doesn't directly capture the audience I'm building for, it can still be a useful tool for collaborating with colleagues as a shorthand. "We are targeting the Baseline YYYY feature set" is rather more portable and transparent than having to do a fresh analysis with your analytics when you see an unfamiliar feature on MDN.
Daniel D. BeckBaseline Maintainer
At an agency like Cast Iron that works simultaneously on projects of varying scale and for widely varying audiences, absent unique client needs and compelling analytics, we don’t want to think too hard about our support policy. Available in all browsers for at least 30 months gives us a strong foundation to build on—we can be confident that our products will work for the vast majority of users—as well as a heuristic for using new web features in a thoughtful way.
Better Integration with Developer Tools
Finally, Baseline grounds our policy in a well-supported web project which is increasingly integrated with tools that we routinely use. This is one of the most promising aspects of Baseline: not only does it provide a shared language for people to use, it creates terminology for the tools our developers use in their work every day.
At the time of writing, this is admittedly more promise than reality, but there is room for optimism. In addition to the key resources online that have begun displaying Baseline data, we have been testing out third-party libraries that aim to integrate Baseline.
One such library is bl2bl, short for “Baseline to Browserslist”. This handy little tool, developed by a W3C WebDX Community Group member, takes a Baseline classification and transforms it into an up-to-date definition of actual browsers. For instance, running npx bl2bl using “widely available” as my threshold setting, bl2bl updates package.json with the following:
While our build tools these days use Browserslist less than they used to, we still regularly use PostCSS, and we maintain plenty of projects that use webpack, Babel, Autoprefixer, and more, so we always include a definition in each project’s package.json.
This package might also be used in combination with eslint-plugin-compat, which uses Browserslist to check JavaScript code for compatibility. However, unless you only use JS client-side, or your project setup has very clear server/client boundaries that you think you can get eslint to understand, then there is a good chance you’ll be sorting through a lot of meaningless warnings.
We have also noticed that ESLint’s official new CSS plugin includes a rule called use-baseline for catching properties, values, at-rules, and other usage that doesn’t fall under Baseline widely available (also configurable to “newly” or to a specific year).
While promising, the utility of this rule is limited by the fact that it requires @supports blocks to use any newly available CSS features. CSS is a forgiving language, and oftentimes there's a simpler approach than @supports for doing progressive enhancement. At the end of the day, skilled developers know more than a linter about how to use browser features in an inclusive way. That said, with some improvements, we may find ourselves using this library in the future.
It is still early days for Baseline to integrate with developer tools. But given the momentum of the project, I expect that we’ll increasingly see its adoption in build and linting tools as well as frontend frameworks. I’m hopeful we’ll also be able to bypass Browserslist and use Baseline directly as a feature target in these tools.
The Verdict on Baseline
Even at this early stage, we have already seen a lot of benefit since updating our support policy late last year. We’re all speaking the same language. We can easily check interoperability for any feature we want to use. And we’re talking a lot more about progressive enhancement. This is a win for everyone involved: developers, clients, and, most of all, users!