Baseline: A Shared Line for Safe Web Features

How do frontend developers know whether a feature is safe to use in production? Historically, the answer involved consulting per-feature compatibility tables or chasing version numbers across multiple browsers. Now a collaborative initiative called Web Platform Baseline aims to replace that with a single, definable standard. Rachel Andrew, staff technical writer and content lead for web.dev and developer.chrome.com, joined the Smashing Podcast to explain how the project works and what it means for browser support strategies.

From Frozen Eras to Fast-Moving Releases

Andrew's career spans decades of web development, and she recalls a very different landscape. "We had five years between IE6 and IE7," she notes, describing a period when the platform effectively stopped moving for a majority of users. "It was very stable. Buggy but at least the bugs that we could list them, there were websites that listed all of the IE6 CSS problems." Being an expert then meant memorizing known browser bugs, not mastering new features. The dominant browser saw the least innovation, which made it difficult to use features that were landing in other engines despite the growing ecosystem promoting progressive enhancement.

That world has vanished. Today, browsers update so frequently that tracking what shipped in which version is no longer a realistic skill. Even Andrew, who documents new releases for a living, admits, "If you said to me, 'Oh, what was in Chrome 113?'... I'd be like, 'Err, was that in that one or was that in the beta?'" The implication for modern projects is clear: tying a support contract to a specific browser version is impractical. "You don't even notice that things update," Andrew notes, because users rarely keep pace with major version numbers manually.

Client expectations have evolved in parallel. The old habit of testing a site side-by-side in two desktop browsers on a monitor has largely faded, replaced by problems surfacing on mobile devices or through performance issues. "Far more likely," Andrew observes, "is someone saying, 'This doesn't work well on my phone.'"

What Exactly Is Baseline?

Baseline was introduced as a core concept during Google I/O 2023, but Andrew emphasizes it is not a Google-only product. The idea emerged from the Web DX community group, with representatives from various browsers collaborating on how to define "safe" for a wide audience. The core principle of working with this group was interoperability, meaning a feature was not just supported by one engine, but worked everywhere without major implementation gaps.

The fundamental goal is to offer a clear, useful distinction for developers. Andrew says they are exploring a way to define and highlight features with cross-browser interoperability, framing it as a potential "marker for safe to use" capabilities. Instead of checking support on a individual property-by-property basis in places like MDN, which most developers find tedious and prone to partial implementation confusion, the project aims to provide a higher-level view of the whole platform.

One of the complexities the project tackles is when a feature is only partially supported. Andrew illustrates this with the case of the gap property in Flexbox and Grid. "You could test for that. You could test for where the gap was supported and a browser would say yes because it was supported in grid layout even when it wasn't supported in flex layout." For this reason, the grouping of features within Baseline is a major undertaking, ensuring that complex capabilities are correctly recognized as fully functional on a platform level. "An awful lot goes into the creation of this sort of feature set grouping," she explains.

Not a Replacement for caniuse

Given the existence of caniuse.com and MDN Browser Compatibility Data (BCD), you might wonder how Baseline fits in. Andrew positions Baseline as complementing those services, rather than duplicating them. Data sites like Can I use, and BCD data, operate on a feature-by-feature basis, providing high detail and specifics that are hugely valuable for pinpoint debugging but require effort to interpret on a full-project scale.

It's not saying to people, 'Oh, you can't ever use these things.' But if you know it's not in Baseline, then maybe theres some things you need to think about there.

Furthermore, these tools do not always cover the entire web platform with the same consistency. They make their own grouping choices which might mislead users; Andrew cites a long-standing issue where "fragmentation" was bundled with "multicol," making it look more troublesome than it is in practice due to standalone bugs. Baseline is instead an aggregation layer. It aims to say definitively whether a capability is considered ready for universal production use. The next step is integrating this data into tools. "MDN are using Baseline on feature pages," Andrew mentions, and they hope to see Can I use adopt and display the information as well.

How Is the Line Drawn?

The criteria for what constitutes a Baseline feature are powerful and open to debate. At launch, the criteria involved looking back at the last two major versions of the major browsers. Andrew concedes, "The line will always be wrong... I think the line will always be." This sparks discussion about Chromium-based derivatives that might lag, or requests to include previous Safari minor releases after it shipped a significant feature. The point is not to be exacting on version points, but to provide a predictable "stable view onto things."

While the intent is to designate what is currently interoperable, the project is also planning for yearly, stable releases. This structure allows focusing on what is available today without having to reassess targets constantly. They expect that teams will align their work with these yearly static definitions, or even track which items are missing from an older baseline year. This creates opportunities for teams to decide which new features are enhancements worth adopting under a yearly timeline, allowing them to discern what is a matter to handle case-by-case, as opposed to universally available.

The Ecosystem Impact

The utility of Baseline extends deeply into the software ecosystem. In a way, it works much like a stable operating system distribution release does for enterprise users. "I think the yearly release will become, I think, quite important," Andrew says. Framework authors or teams building third-party components can reference Baseline to let end users know about compatibility in a clear way.

Another benefit is the ability for articles and docs to be labeled as "safe" — which is invaluable for busy developers looking for reliable solutions. "If people get halfway through an article and then they find something that is experimental or is so new or only works in Chrome or whatever, that's really frustrating." Content producers can label tutorials using Baseline, which removes obstacles to immediate adoption of new techniques.

Thinking about the long view, can a feature fall out of Baseline? The team has discussed this scenario, since engines rarely delete features but do not exactly maintain them either. If an engine unexpectedly causes a regression on a stable feature, or something is deprecated yet kept for the sake of the web's longevity, Baseline offers the infrastructure. It would make this much more visible than today, and introduces pressure on teams to fix issues on prioritized features that are widely relied upon.

The Interop Connection

One of the core signals of the state of the web has been the interdisciplinary Interop Project (formerly Interop 2022). Andrew explains that Baseline and Interop occupy different sides of the same coin. "Interop project takes a set of features that have some sort of interoperability problem. It might be that they don't work in one or more browsers or they have sort of bugs... all of the engines work to implement or fix those things."

So, whereas Interop is fixing what's broken, Baseline is holding up the results. By defining what has achieved interoperable status, the industry gets a formalized snapshot of their work. They're connected in the sense that the people involved and goals of broad improvement often overlap, though they have distinct ways of helping developers.

Getting the Most Out of the Web Platform

During the episode, Andrew looked beyond the immediate release of Baseline with great excitement. The resources are currently moving from raw data to prominent status in authoring tools and docs. On the team's own properties, web.dev focuses on stable and shared knowledge for current APIs best practices, whereas developer.chrome.com hosts developer documentation, including new things coming down the pipeline from that vendor, such as the Popover API and working with the open UI group on things like scroll-driven animations.

Her ultimate vision? That the new-found clarity will show just how fast the platform is accelerating. The upcoming collaborative push aims to complete and tag near-by concepts like the latest CSS and JavaScript specifications with ease. She illustrates a broader shift: "
container queries and cascade layers... landed cross browser very, very quickly, which is great. This can help tell that story."

This episode references a one-time interview on the Smashing Podcast. Learn more about Baseline and current status on the links below, and use GitHub to follow the discussion with those shaping the standard.