I find caniuse to be a very good resource to check for these kinds of things. Here are the stats for nesting:

https://caniuse.com/?search=CSS%20nest

Aside: Shouldn't browsers update themselves these days? Any reason to turn this off? Seems silly from a security perspective.

> Shouldn't browsers update themselves these days?

They should. But in the same way, admins and guidelines in authorities and large corporations should now follow a more modern update strategy. "Never change a Running System" is unfortunately still a popular, lazy excuse.

In a way I can understand them - there are often things people are used to breaking or changes in the UI with software updates (not so much with browsers usually I guess). I can sympathise with older or less technical people who are afraid of an update forcing them to “relearn” how to do something they are used to.

Edit: not so much large corporations tbh.

I don't know exactly when this changed, but I always see people (devs and users alike) leave their Chrome open and waiting for an update, sometimes for weeks or months.

I guess if they just put their machines to sleep and never fully quit Chrome, it never has a chance to self update.

Am I crazy for thinking that Chrome should be designed in a way where individual tab rendering processes should be able to upgrade without having to close and restart the entire cluster of processes? The actual browser UI shell very seldom needs updates...

I don't know the internals of chrome (I'm sure someone else here does), but that sounds like they'd be containerizing a bunch of runtime inside tabs. Would probably blow up memory usage. But not sure what their current tab sandboxing already entails.

> Shouldn't browsers update themselves these days?

Looking over the shoulder of a user who’s fairly savvy—but doesn’t understand just how horrifying browser security is—revealed at least one pitfall to me: an update needs a restart of the browser, and a prompt to restart appears specifically when the user turns to the browser, presumably, in order to use it, that is, at the worst possible moment. As a result, it gets postponed indefinitely.

(Forced restarts when the browser thinks you’re not using it are also a bad idea for reasons that are hopefully obvious to anybody who’s used a modern version of Windows. That is not even counting the general vibe of knowing better than the user what they want, which I just instinctively dislike.)

Just like Chrome had a whole thing about process isolation to avoid crashing the entire system, it would be quite excellent if they could figure out how to effectively update at a tab-based level. New tab? Get the newest Chrome in the tab.

Obviously would be quite frustrating to debug a thing only to realize tab A is version 1 and tab B is version 2 of course. And it seems like it would require a massive amount of effort. Would be cool though!

Doesn't chrome also put tabs into "standby" (i.e. kill them) by default? Then this would update most tabs for most users.

Why not update all tabs at once then?

The key feature would be to maintain the exact state of a tab between process restarts.

Then they could restart the whole browser without the user noticing

If you use an ESR browser, you’ll get security updates, but not new features. Some users prefer this as providing more stability and possibly better security.

Firefox ESR is updated with new features about once per year, so that’s probably the minimum time one should assume for new features to become universally available.

Aside: Shouldn't browsers update themselves these days? Any reason to turn this off? Seems silly from a security perspective.

That requires a mutable filesystem, which also seems silly from a security perspective. It would also require granting permission to mutate/replace executables to a program that's exposed to untrusted input (i.e. a browser).

> Aside: Shouldn't browsers update themselves these days? Any reason to turn this off? Seems silly from a security perspective.

They should. But we have iPhone users who get an update to their browser every 6 months(?) and even then, it's still behind on features most of the times.

> That may be true, but most people don't update their browser every month[

Yes they do? All modern browsers are updated automatically with the OS. It's true that not everyone is on exactly the same cadence and there are always stragglers, but if you look at your second link the time to decay to near zero for any given browser release is almost always two months from the release of the next.

Plenty of people don’t update their OS, either out of laziness, fear, or just because their device is no longer supported on the latest version.

Sent from my iPhone running iOS 16.

It's a horrifying thought, but the truth is... some people don't upgrade their OS very often. Or at all. Or as the sibling comment says, they use an Android phone or iTrinket that isn't getting updates, limiting what apps can be installed.

> It's a horrifying thought, but the truth is... some people don't upgrade their OS very often.

Vanishingly few, though. Again, there's data in the upthread links, and it says that after two months a stale release has effectively disappeared.

The “Baseline” initiative now has a useful suggestion: their “wider support” high compatibility status is “all major browsers have been shipping it for 2½ years”. See https://github.com/web-platform-dx/web-features/blob/main/do... for more details. (When they first announced Baseline, its definition was disastrously bad, generally only covering ⅔–¾ of actual users, but I’m pleased they’ve listened to feedback and redone it completely; the definition it has now is a little more conservative than I’d have gone for—I’d have gone 2 years—but that makes it even more dependable, where that status is achieved.)

Picking jut a couple of these specific features:

• CSS Nesting as a whole is only 4–8 months shipped, and the “relaxed nesting” only shipped earlier this month in Chromium and Safari. At this point, you should absolutely not “drop those extra &”, and almost certainly not depend on nesting at all yet. And since it’s syntax, it’s not really a progressive enhancement candidate. So this becomes just a “don’t ship nesting syntax for another year or two”. Author with it and transpile down to compatible syntax with something like Lightning CSS, by all means.

• color-mix() is only 7–12 months shipped, though as a saving grace it’s Safari that’s the oldest (Safari is the browser most commonly far out of date in features due to Apple’s tie-browser-updates-to-OS-updates approach). It’s not generally a good idea to depend on color-mix() yet, though there are some progressive enhancement cases where it’s reasonable. For example, `text-decoration-color: color-mix(in srgb, currentcolor, transparent 50%)` makes underlines semitransparent, and it probably doesn’t matter if the browser skips that.

Does anyone actually really care about the compatibility still? For quite a while now, I have relied on PostCSS/Vite presets just doing the right thing, transpiling my CSS to whatever is most compatible. And that’s how it should be - from all the important things to know about the web platform, developers really shouldn’t spend their time fine-tuning compilation artifacts by hand anymore.

Syntax features like CSS Nesting can be translated into something older browsers can understand. But other features either can’t be translated, or can only be translated in some cases. For example, color-mix(in srgb, red, blue) can be computed as purple at compile time; color-mix(in oklch, var(--a), var(--b)) can be computed iff --a and --b are known to have single static values; and color-mix(in srgb, currentcolor, transparent 50%) fundamentally isn’t known until runtime (even with DOM knowledge, you can’t say “currentcolor is always purple, therefore, &c.”, because the user agent may force colours).

So yes, you absolutely still need to care about compatibility. This isn’t about fine-tuning compilation artefacts by hand, this is about browsers lacking features that you’re trying to use.

>Safari is the browser most commonly far out of date in features due to Apple’s tie-browser-updates-to-OS-updates approach

I love Safari, it's my browser of choice, but this behavior must change. It's easy to miss an OS upgrade (it's a big deal, takes time, may break things, etc) and as a consequence, being 3-4 versions behind is not uncommon. People end up switching to Chrome on old systems because sites are broken in Safari. Evergreen browsers have been the future for more than a decade. It's the only way to go.

Safari is not tied to OS updates on Macs.

Wow, I completely missed the news on relaxed nesting making its way into browsers. That's fantastic. The whole "you should usually include an ampersand, but sometimes it's not required" rule was really frustrating as a concept.

I get that it took some engineering changes on the parser front, but this is so much cleaner as far as syntax goes.

I reckon it was a mistake and they should have always required an &. But when they were surveying, they refused to even consider this option for reasons that I don’t recall but which I think seemed weird to me.

I find the "Usage relative" and "Date relative" tabs on caniuse.com to be very useful for this: https://caniuse.com/?search=color-mix

And it totally depends on your market. If you're Facebook you probably have to support 10 year old browsers.

If you're running some fun unpaid sites like me, then screw everyone with an out-of-date browser, I'll do what I want.