I'm also frequently surprised at how long certain CSS features take to implement. Some recent examples for me are the `has:()` pseudo selector [1], the scripting media queries [2], and css nesting [3].
[1] https://caniuse.com/css-has
[1] https://caniuse.com/css-has
`:has()` is very clever, powerful, and has been desired for a long time. However, even if someone figured out how to implement it twenty years ago, it probably still couldn't have been used for performance reasons.
CSS nesting may have also been infeasible for performance reasons.
If your styles are defined within external stylesheets, then having to extract them from their respective stylesheets and place them directly in a noscript DOM node is not very ergonomic (and it will also affect your ability to cache those styles, since they're now a part of your potentially dynamically generated HTML rather than a static stylesheet).
> use JavaScript itself to add or remove a class that is used within the relevant selectors.
Well yeah, If you're ok with adding JS then most native CSS features can be polyfilled. This is a very imperative solution to a problem that the scripting media query handles declaratively. I would much rather have my styles dictated by my stylesheets, and reserve my JS for adding interactivity.
> However, even if someone figured out how to implement it twenty years ago, it probably still couldn't have been used for performance reasons.
Yeah the has selector is similar to a lookahead assertion in a regular expression, and CSS nesting is similar to a lookbehind (both of which can be computationally expensive). I'm not sure browsers needed to wait until the 2020s to deliver these features though. I would have loved to ditch SASS and SCSS years ago.
Yes, there's probably been enough device performance to handle things like :has() and CSS nesting for a while. Another factor may have been IE; as long as there was a browser that wouldn't add features but still had to be supported, interest in expanding CSS spec in ways that couldn't easily rely on CSS parsers ignoring code they don't understand may have been limited.
I get how it works, it just feels like a hack designed to work around a missing feature, rather than the ideal way to handle the problem. Phrased another way: if the scripting media query was ubiquitous I would never go back to toggling classes via JS.
> Another factor may have been IE;
Browsers have been shipping features that don't work in IE for the better part of the last decade. If you think CSS nesting would break IE, imagine what IE would do when it encounters a modern JS feature that can't be polyfilled like Proxies.
I am asserting that in the majority of cases where a person's browser is not running a page's JavaScript, it is because of a network failure or intentional blocking, neither of which can be detected by the media query.
Therefore, three years from now when the media query will be ubiquitous, it won't prevent your styles that are meant to be used only with your JavaScript from being used most of the time.