> cases where you don't need to set a value
I don’t know what you mean.
> when your condition requires a more complex selector (e.g., a parent/root context)
I don’t see the problem. :where() takes a <complex-selector-list>.
I don’t know what you mean.
> when your condition requires a more complex selector (e.g., a parent/root context)
I don’t see the problem. :where() takes a <complex-selector-list>.
You are probably right about `:where`, but using it with complex selectors might noticeably affect the performance, as it does with `:has`. Didn't run any test for `:where` specifically, though. Also, we apply lots of styles to the same elements, most of which are overridden.
Another issue is using a different set of longhand/shorthand properties for different states that won't be correctly overridden in this approach.
So it might work pretty well in most of the cases, especially simple ones. But it's definitely not better than mutually exclusive selectors.
revert-layer <https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...> may be relevant to the situation you describe. Not the simplest thing, but it’s a tool most don’t know about yet which can do that kind of thing.
—⁂—
On :where(). It’s easy to see why :has() can tank performance: it’s doing a whole new complicated thing. :where() is a good deal simpler, and this specific form of it (where it’s the entire selector) has only the effect of zeroing specificity. I’d be mildly surprised if the performance difference from wrapping an entire selector in :where(…) was measurable even in a worst-case synthetic document.
Tasty doesn't fight cascase; it fights ambiguity in source order and specificity. Cascade might still be useful for many things.