Baseline goes mainstream: what the 2025 I/O roundup means for your tooling
The 2025 "What's new in web" keynote at Google I/O doubled as a progress report for Baseline. A year after the initial push to make browser support data machine-readable and widely available, the ecosystem has moved well beyond documentation pages. The web-features data set is now complete, covering every feature of the platform, and the Web Platform Dashboard reflects each month's new Baseline additions. What follows is a rundown of the tooling and integrations that have landed since, all of which aim to turn Baseline from a reference concept into an automated part of your daily workflow.
Picking a target that fits your actual users
Baseline Widely available remains the popular moving target—UK agency Clearleft builds its browser support policy around it—but it is no longer the only sane choice. You can now fix a target to a specific Baseline year, and two new integrations help you decide which year that should be, using data from your own users rather than a global average.
RUMvision's Baseline integration, announced at last year's I/O, is now live. Because it works from your Real User Monitoring data, it can show you which Baseline year your traffic actually supports, and whether Widely available even makes sense for your audience. A similar check is available for Google Analytics users via the new Baseline Checker, which reports the percentage of users that support each target.
These tools are part of a growing wave of vendor integrations. The Web DX Community Group has also published a Netlify extension that surfaces Baseline year and Widely available status on your sites. Cloudflare's Observatory RUM product and Contentsquare integrations are reported to be in the works.
Mapping browser versions to Baseline in your own code
The web-features data set remains open, and pulling it into your own tools has gotten simpler. You can query the Web Platform Dashboard API, or consume the data directly through the web-features npm package. For version mapping, the baseline-browser-mapping module from the W3C WebDX Community Group now converts browser versions into Baseline targets. It runs in server-side JavaScript, or you can download pre-generated JSON or CSV files that refresh daily from the repository. The data covers not just the core Baseline browser set but downstream engines as well, including Samsung Internet, Opera, UC Browser, and Android WebView.
Bringing Baseline into the build and lint step
Baseline info already lives on MDN, Can I Use, the Web Platform Dashboard, and documentation on web.dev and CSS Tricks. The next logical step is having it appear where you write code, without leaving your IDE or stopping your build. Several key tools now have Baseline support built in or available as a plugin.
browserslist-config-baseline is a collaboration between the Chrome team, the WebDX CG, and community members that lets you express browserslist targets in Baseline terms—widely available or a specific year. Any tool that consumes a browserslist target, like Babel or PostCSS, can now be configured against Baseline directly.
For linting, ESLint for CSS ships a use-baseline rule. Configure it with your target and it flags anything newer, with two ways to resolve the warning: replace the feature with more primitive equivalents, or suppress the warning—a valid approach when you're knowingly using a cutting-edge feature as a progressive enhancement. By default the rule leaves @supports blocks alone, since unsupported browsers won't evaluate them anyway. Stylelint gets the same treatment via stylelint-plugin-use-baseline. For HTML, a community plugin called html-eslint covers that space. Most of these linters have IDE plugins, so the warnings surface as squiggly underlines while you type.
Hovercards that speak Baseline
IDEs have long shown browser version lists on hover, but interpreting those lists—checking whether major browsers are missing, and how recent their versions are—takes effort. Both VS Code and JetBrains WebStorm are now removing that guesswork by adding Baseline data directly to their hovercards.
In VS Code, hovering over a CSS property, HTML element, or HTML attribute now tells you whether it's Baseline and how long it has been so, or whether any major browsers still have incomplete implementations. Since the integration is in VS Code itself, any editor built on it inherits the feature.
JetBrains has announced a similar implementation coming to WebStorm for JavaScript and TypeScript development.
Interop 2025: Features Moving Toward Baseline
The combination of Baseline status and the Interop 2025 project means more features are heading toward full interoperability than ever before. Alongside the improvements already marked as Baseline Newly available, a slate of features is tracked on the Interop 2025 dashboard.
Sideways writing modes
The sideways-rl and sideways-lr values for the CSS writing-mode property have become Baseline Newly available. When vertical writing is only needed for layout, these values are the more obvious choice.
h1 {
writing-mode: sideways-rl;
}
h2 {
writing-mode: sideways-lr;
}
Anchor positioning
Anchor positioning, shipped in Chrome 125, connects an element's position to an anchor element—for example tying a tooltip to its trigger button. It is now included in Interop 2025 and expected to join Baseline this year.
Core Web Vitals: LCP and INP
Interop 2025 targets both the Largest Contentful Paint (LCP) metric through the LargestContentfulPaint API and Interaction to Next Paint (INP) via the Event Timing API, implementing them consistently across browsers.
Improvements to <details>
The <details> element is already Baseline Widely available, but Interop 2025 includes several enhancements that make disclosure widgets more flexible. The element contains a <summary> that stays visible, with the remainder of the content hidden until the user expands it.
During Interop 2025, browsers work to hide the content with content-visibility rather than display, meaning collapsed content is never rendered. Additionally, the ::marker pseudo-element lets you style the disclosure triangle on <summary>.
The newer ::details-content pseudo-element targets the portion of the <details> element that expands and collapses, giving you direct styling control over it.
Several other improvements are part of the Interop 2025 scope, including auto-expanding a <details> element when it matches a find-in-page query, and support for the until-found value of the HTML hidden attribute. This hides an element until the browser's find-in-page search or a URL fragment navigation reveals it.
CSS @scope
The CSS @scope at-rule constrains selector reach. Any style rules nested in @scope apply only to the DOM tree under the scoping root defined there. For instance, targeting <img> elements solely within a .card element makes .card the scoping root.
@scope (.card) {
img {
border-color: green;
}
}
scrollend event
The scrollend event resolves the lack of a reliable way to detect when a scroll ends. Instead of self-monitoring scroll positions, the browser evaluates when scrolling is fully complete and fires the event on your behalf.
Same-document view transitions
Same-document view transitions, covering single-page-app navigations and view transitions classes, are also part of Interop 2025.
These features are not the only ones slated to become Baseline Newly available this year, but their inclusion in Interop suggests they are prioritized and close to cross-browser support. You can see more detail on all features that reached Baseline since May 2024 on the Web Platform Dashboard.
From backfill to ongoing updates
The data backfill for web platform feature status is now complete. With that foundation, a wider range of developer tools can make use of the information—and the project continues to grow rather than wind down. If your project or open source tool could benefit, the maintainers are interested in hearing about it.
Updates on new tools and walkthroughs will continue to run on web.dev.
