I saw Tony Conway & Jeremy Wagner’s post on web.dev, Use Baseline with Browserslist, and I had a little play with it myself (saved live stream). Allow me to write down what I know and what I learned.
So here’s Browserslist1.
Browserslist is the developer community at it’s best. There are a bunch of tools that make choices about what they do based on what browsers they are trying to support. Like the intro on their homepage says:
Shared browser compatibility config for popular JavaScript tools like Autoprefixer / PostCSS, Babel, ESLint, and Webpack
Links to those tools added by me, linking to their Browserslist details. LightningCSS is another one.
So instead of all these tools coming up with their own syntax for how to express a set of supported browsers, they all use this shared syntax. And not even just a shared syntax, they can even share the same location or file (i.e. .browserslist) to store that information.
That’s great. It’s in the same vein as the famed package.json file being the canonical source of packages and JavaScript processing information, or .editorconfig for all editor behavior and prettification needs.
Browserslist recommends "defaults" if “you’re building a web application for the global audience.” This translates to their config "> 0.5%, last 2 versions, Firefox ESR, not dead". That translates to any browser which has more than half a percent of browser share (it gets browser data like this), the last two major versions of all major browsers, Firefox “Extended Support Release” specifically, and only “not dead” browsers (as in, not Internet Explorer).
That’s pretty reasonable? But you can always add things to your support list if you need to go deeper or be more specific.
But now Google is in the game of qualifiying web platform features with Baseline.
Web Platform Baseline brings clarity to information about browser support for web platform features.
Their biggest rubber stamps are “widely available” and “newly available”.
- Baseline Widely available includes all web features that were fully supported by the Baseline core browser set 30 or more months in the past.
- Baseline year feature sets, for example Baseline 2020, include all features that were Newly available at the end of the specified year.
This means you can literally use Browserslist config strings to use these delegations.
"baseline newly available"
"baseline widely available"
"baseline 2022"
Specifying a year, like the last example above, might be how your project wants to roll! I don’t hate it, honestly. If I were to use "baseline 2020" as config and run CSS through Lightning CSS, I’d see some transformations like this:
oklch() not supported at all, so transformed into three different formats, supporting as much as it can. light-dark() not supported at all, so provides custom properties for your own implementation, and mask is vendor prefixed.If we went back to "baseline 2018" we’d even see some big transformations of padding-inline-start transformed into padding-left for a big ol’ pile of :lang() values and padding-right for another big pile (!!).
If we went forward to "baseline 2022" we’d see the color() declaration go away, leaving only the #hex and lab() values left, but the rest would be the same.
I think the general “recommendation” (if that’s fair) is to use "baseline widely available" where our CSS transformations are like this:
oklch() color is left alone, but we still see the light-dark() transformation and the vendor prefixing for mask. Using "baseline newly available" is still somewhat cross-browser compatible, just not to the level of widely available. To be “widely” available the feature needs to be baseline for 30 months! So I’d say pretty-darn available. Using "baseline newly available" we get:
Example Repo
I tossed together a repo for testing this stuff. You can basically change the config here. It’s an npm run dev thing and it’s wired up to not fingerprint or minify, so it’s easy to see both src and dist files like the screenshots I was doing above.
It’s also wired up to do JavaScript processing with Babel, although I’m not 100% sure I even did that part right, but if you wanted to test JavaScript transformation on this stuff, it might be a good starting point.
Stuff That Isn’t Touched
Remember that CSS features aren’t always transformable to backwards-compatible things. Like if you use @layer or rlh units or something, that’s just going to get left alone despite any browser support levels. Same with stuff like shape(), which is brand new, and would be awesome if they ported it to something, but alas, they do not.
Final Thoughts
I think it comes down to a battle: "defaults" vs. "baseline widely available". Anything else is just playing around or very specialty situations. Between the two, I think I’d actually go with "baseline widely available". It just seems a smidge more modern and I like the momentum behind it.
The best possible move is to use your own analytics data to inform the choices. This can be done with a Baseline Target Report and Jeremy Wagner and Rachel Andrew get into it in How to choose your Baseline target.
- The pluralization of Browserslist is weird. Feels like it should be Browserlist. You’ll also see config strings like “last 2 version” which then lacks the pluralization it wants (but it also works pluralized). 🤷♀️ ↩︎
