You don’t.

Safari has supported CSS nesting since v16.5. The specification was updated to remove the earlier requirement to use & though, and support for that was introduced in v17.2. As long as you include the &, you can support everything back to v16.5.

Not sure what you are referring to regarding Windows < 10, but Windows 10 was released nine years ago. Only a tiny fraction of web developers need to support decade-old clients.

If you do need to support browsers that don’t understand CSS nesting, use PostCSS or Lightning CSS. They will transcode your nested CSS to older syntax browsers support. Then, when you drop support and remove those browsers from your browserslist, they will stop transcoding it and the CSS you deploy will get smaller. But you’ll have been writing standard nested CSS all along.

If you want to use the normal non-& syntax, then you will need to use Safari 17.2, yes.

I am referring to the fact that there are no browsers with native CSS nesting that support Windows < 10.

> If you want to use the normal non-& syntax, then you will need to use Safari 17.2, yes.

Non-& is not “the normal syntax”. It was a late addition to the specification. Both with and without & are normal, but with & has better compatibility.

Even if you don’t use the &, you can still write nested CSS and support older versions of Safari, like I said. Use PostCSS or Lightning CSS. There are normally several areas where you can start writing modern CSS today and fill in the backwards compatibility with these tools. It’s not just nesting.

https://preset-env.cssdb.org

https://lightningcss.dev/transpilation.html

I guess we will have to disagree about what is normal or not. Perhaps it depends what tools one was using before going CSS native.

Obviously I'm talking here about direct serving of CSS assets without precompiling.

why wouldn't this work?

> You’d need a separate stylesheet to support everyone.

In theory it can, but when you work with 20 other devs all working on the same codebase, tracking those changes can become burdensome.

Are we going to add an entirely new testing suite and workflow tools to save 5 lines of legacy CSS in favor of the new version? Probably not in a lot of teams.

You also need to write and maintain code to conditionally load that fallback stylesheet and hope your users aren't using some weird user agent hacks (looking at you instagram in-app browser).

All of these problems can be solved, but obviously nobody wants to because the juice is not worth the squeeze. This is not our first rodeo. I'm gonna wait another 18-24 months and then start using most of the features released this year. It's fine.