Published: May 1, 2025
April was a busy month for Baseline, with lots of tooling updates, some Newly available features, as well as some features that have become Widely available. Get up to speed quickly in this edition of the Baseline monthly digest!
Baseline Newly available features
The following features became Baseline Newly available this month:
Baseline Widely available features
The following features became Baseline Widely available this month:
Support for Baseline CSS and HTML features lands in Visual Studio Code Insiders
Much work has been done on the tooling front for Baseline, and perhaps one of the biggest pieces of news in this area is that work has been done to integrate Baseline into Visual Studio Code. In the Insiders build, there is now support for Baseline CSS and HTML features in the form of tooltips when you hover over CSS rules and HTML elements.
This update is a nice upgrade that quickly lets you know whether the features you’re using in your project’s HTML and CSS are broadly supported or not. While it’s currently in the Insiders build, it should reach stable at some point in the near future.
This change will also become available in other VS Code-based IDEs. Meanwhile, support has already landed in Zed. However, note that there’s a known issue affecting the display of the Baseline icon.
Stylelint adds support for Baseline
Not long ago, support for CSS landed in ESLint, and with it included a rule for linting use of CSS features based on their Baseline status. However, Stylelint is another tool has been used for linting CSS, and it also recently landed support for Baseline in the form of the stylelint-plugin-use-baseline plugin.
This rule works very similarly to ESLint’s, but is available for developers who prefer Stylelint over ESLint for CSS. If you want to get an idea of how you can add it to your existing Stylelint configuration, you can check out the package documentation, or check out the Stylelint tooling demo we’ve created that shows it in action!
ESLint updates
ESLint continues to land updates to their CSS linting capabilities, and this has resulted in a few changes and additions to the use-baseline rule:
- You can now target Baseline years in your configuration. Before, you could only use the “newly” and “widely” values in your configuration, but now you can specify a specific Baseline year, giving you much finer control over how your use of CSS features triggers Baseline-specific warnings or errors.
- Support for selectors is now available. Initially, only some parts of stylesheets could be linted for Baseline support, despite the fact that selectors are also a type of CSS functionality containing discrete features that can become Baseline. With this update, selectors can now be linted.
- Support for many more CSS functions have been added, such as
color-mix,conic-gradient, and many more. - ESLint will now warn by default. This is designed to create a default in which a build won’t throw errors if you don’t specifically tell ESLint to. Opt into throwing errors if your project requires it.
As time goes on, more updates to the use-baseline rule will land—and as they do, they will be covered here and in other blog posts as necessary.
browserslist-config-baseline launches
Modern toolchains use one or more tools that are influenced by a Browserslist configuration (or assumed default). These configurations are used by tools such as PostCSS or Babel, and their output can be influenced by the content of them.
We’ve long wanted to see tooling take a Baseline target as input—such as Widely or Newly available, or even Baseline 2024, for example—and output a valid Browserslist query. Now that the browserslist-config-baseline package has been released, it’s possible for you to do just that.
The ability to translate a Baseline target into a valid Browserslist query is huge. Depending on the features you use in your projects, you have a great opportunity to tailor the output of your project’s CSS and JavaScript—including even polyfilling with core-js and Babel. This means you can ship less code in production, which can have some positive performance implications for your project.
For more information, check out our tooling demos for both Babel and PostCSS to get an idea of how this might work in your existing toolchain.
If you’re looking to get under the hood with browserslist-config-baseline it’ll be helpful for you to know that it depends on the underlying baseline-browser-mapping package, which recently added some new features:
Baseline on the RUMvision webinar
Recently, our own Tony Conway appeared with Erwin Hofman on a webinar with RUMvision. As a Web Ecosystem Consultant with Google, Tony brought an excellent primer to Baseline to the webinar, along with a deep dive into how it all comes together with the work multiple teams here at Google are putting in to make it useful for developers. It’s a great way to get up to speed on how it all works, and we recommend you take a bit of time to check it out.
As you might have noticed in a couple of other places in this edition of the monthly digest, we’ve linked out to a few demos in our baseline-demos GitHub repository. There’s some really cool stuff in these demos that shows what you can accomplish with Baseline in various tooling pipelines and other applicable uses—such as integrating a Baseline MCP server with your AI coding agents, so you can modernize your generated code by making it more Baseline-aware.
As time goes on, we’ll be adding more demos to the tooling section of this repository. As we do, we’ll be sure to call them out in future editions of the digest.
That’s a wrap!
April was a pretty busy month for Baseline—and as we approach Google I/O, we expect even more developments in this space. Keep an eye out for new articles on Baseline, as well as blog posts. If you miss out on anything, we’ll be sure to get you caught up in the May edition of the monthly digest.
As usual, let us know if we missed anything Baseline-related, and we’ll make sure it gets captured in a future edition. See you in a month!