6 ms·

> All of these features are available today, as of this reading, with every major browser supporting them in the current version That may be true, but most peo

> All of these features are available today, as of this reading, with every major browser supporting them in the current version That may be true, but most people don't update their browser every month[1][2] (data isn't readily available it seems, but I'm sure as a webmaster you'd be logging User-Agents and can see the long tail for yourself). So if you want or need to reach a wide audience—say, if you're writing a storefront for a business, or an e-government portal—the only new features you can use are those which fail gracefully, namely ones that are syntactically valid under the old spec+parsers. [1]: https://www.stetic.com/market-share/browser/ https://www.stetic.com/market-share/browser/ [2]: https://gs.statcounter.com/browser-version-market-share/desktop/worldwide https://gs.statcounter.com/browser-version-market-share/desk...

dmalik 3y ago
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 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.
- Ringz 3y ago
  > 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.
  - sjfjsjdjwvwvc 3y ago
    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.
- solardev 3y ago
  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.
  - saurik 3y ago
    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...
    - solardev 3y ago
      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.
- mananaysiempre 3y ago
  > 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.)
  - rtpg 3y ago
    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!
    - smallnix 3y ago
      Doesn't chrome also put tabs into "standby" (i.e. kill them) by default? Then this would update most tabs for most users.
    - jokethrowaway 3y ago
      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
- layer8 3y ago
  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.
- chriswarbo 3y ago
  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).
- berkes 3y ago
  > 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.
ajross 3y ago
> 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.
- zarzavat 3y ago
  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.
- YoshiRulz 3y ago
  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.
  - ajross 3y ago
    > 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.
chrismorgan 3y ago
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/docs/baseline.md#wider-support-high-status 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.
- 9dev 3y ago
  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.
  - chrismorgan 3y ago
    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.
qingcharles 3y ago
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.

dmalik 3y ago

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 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.

Ringz 3y ago
> 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.
- sjfjsjdjwvwvc 3y ago
  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.
solardev 3y ago
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.
- saurik 3y ago
  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...
  - solardev 3y ago
    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.
mananaysiempre 3y ago
> 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.)
- rtpg 3y ago
  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!
  - smallnix 3y ago
    Doesn't chrome also put tabs into "standby" (i.e. kill them) by default? Then this would update most tabs for most users.
  - jokethrowaway 3y ago
    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
layer8 3y ago
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.
chriswarbo 3y ago
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).
berkes 3y ago
> 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.

ajross 3y ago

> 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.

zarzavat 3y ago
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.
YoshiRulz 3y ago
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.
- ajross 3y ago
  > 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.

chrismorgan 3y ago

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/docs/baseline.md#wider-support-high-status 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.

9dev 3y ago
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.
- chrismorgan 3y ago
  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.

qingcharles 3y ago

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.