It's also just kinda bad. Like, people were celebrating the has() pseudo class allowing them to do things with selectors that would be trivial in XPath in its first version 20 years previously.
I will give the people who work on CSS props though, they are the only ones interested in advancing browser's capabilities as something more than just a JS runtime, that is to be commended.
I imagine it's a difficult language to ride the saddle-point of capability and performance. A declarative language like that seems like it'd be easy to design a feature that, as a side-effect of existing at all, slows rendering globally by 5%.
IMO, browsers should throw their hands up and say "if the developers want to do that, it's not our problem" more often. The argument that people would migrate to some browser with a faster CSS engine is a bad one for the cases where it's impossible to handle bad code with good performance.
There are too many good features that aren't being added to CSS because browsers don't want to slow down on bad sites.
If a feature can't be used without the site using it becoming one of those bad sites then it's not very useful (that was absolutely the case with `:has` until the Safari team figured out a trick to implement it performantly - after which the other browser promptly adopted the same trick and implemented the feature).
I will give the people who work on CSS props though, they are the only ones interested in advancing browser's capabilities as something more than just a JS runtime, that is to be commended.