So here’s Browserslist¹.

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:

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:

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.

1. 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). 🤷‍♀️ ↩︎

Code is ephemeral. What works right now might get deleted next month.

That is no judgement on the code, it is a statement that code isn’t the value prop, the product is.

I try and remember this during code review, because even though we call it code review, there is a person at the other end.

Sometimes it makes sense to ask for a refactor, for the sake of the code.

Sometimes it makes sense to approve it and get on with your day, for the sake of the person.

Assume the role of a humble project manager, tasked with delivering a website brief for one of your agency’s clients. Unbeknownst to you, the project is cursed by a dark force determined to infinitely extend the job, and send you into a delirious state of madness.

The agency that made it has a pretty sweet website, too.

1. Use GIMP (free, open-source)
2. Use Affinity (was ~$50, but a one-time cost)

But now, Affinity is free (and all the varieties combined into one app). You can thank the Canva acquisition for that. You might think that would hurt GIMP usage, but I suspect it won’t as GIMP runs on Linux (which neither Adobe or Affinity do) and it feels… Linuxy. I can’t imagine Adobe is happy about it. Canva says “there is absolutely no catch whatsoever”, and also that their mission is to “build one of the world’s most valuable companies” so, ya know, you make the call.

… the tools do provide you with information most of the time. You genuinely just need to take a few extra seconds and read what it is saying.

It seems like the ideal behavior would be “hide the interactive element for a brief period, then if the relevant JavaScript isn’t ready, show the element.” But how?! We can’t count on JavaScript for this behavior, which is the only technology I’m aware of that could do it. Rock and a hard place!

Scott Jehl blogged For Your Convenience, This CSS Will Self-Destruct, including an idea that fits the bill. It’s a @keyframes animation that hides-by-default then fades in after 2s. With this in place, in your JavaScript, you’d include a bit that ensures the button stays hidden, with a new class. That’s a win!

… a site’s JavaScript files can often take many seconds to load and execute, so it’s great to have something like this ready to bail out of anything fancy in favor of giving them something usable as soon as possible.