3 ms·
The biggest problem is that it would completely kill all of the precomputation style engines do to make CSS matching fast. When you style an element, you don't
by Sesse__ 4y ago
The biggest problem is that it would completely kill all of the precomputation style engines do to make CSS matching fast. When you style an element, you don't actually go through the steps of matching it against every rule; but if the selector could change at any time, you basically would have to, and performance would tank completely.
The other issue is that custom properties inherit, so now it's unclear what element you should fetch your var() from (you can't fetch it from the element you're styling, since you haven't computed its style yet). E.g.
.user:has(var(--has-path)) { --has-path: match(.something .else); }
- bryanrasmussen 4y ago>The biggest problem is that it would completely kill all of the precomputation style engines do to make CSS matching fast which is why I specifically said it wouldn't work because of performance issues? This part here at the end >it does seem like it would be expensive (for browser performance) to implement. >The other issue is that custom properties inherit I'm not sure I see the problem with that actually - If I set a value on :root and then override it on .foo then I thought it only got overridden for the descendants of .foo? on edit: ah no of course you mean that if I set --base-color on .foo it is also available for .foo, but in that case I would think the rules would mean that use in selector was outside the scope of the element, that is to say scoped to the parent.