Open romainmenke opened 1 week ago
Re-targeted this against css-conditional, since container queries are being moved over there, and out of the contain spec.
If we can do something like this, it would be useful. I'd be curious about trying to integrate it more into container queries - but I'm not sure if that only makes it more complicated.
The primary limitation here that CQs solve is the potential for dependency loops. As I understand it, that's easier to resolve property by property (with the if()
function). If we create a loop with this syntax, does it invalidate the entire block?
.foo {
--color: pink;
background-color: blue;
@element style(--color: pink) {
--color: not-pink; /* certainly this is invalid */
background-color: pink; /* but is this applied? */
}
}
I imagine we can come up with an answer to that question, as far as feature design goes. But I'm not sure how hard it is to implement.
My thinking: we already can have multiple ways to have inline conditionals: https://lea.verou.me/blog/2024/css-conditionals-now, and some of them working almost as “block”-level ones as well (the @keyframes
one), and then at some point we will have proper inline conditionals (as already mentioned), and any block-level conditional can be expressed as an inline one, a block-level @element ()
(or @if
, in case we'd want to align it with the inline one) could be purely a syntax sugar and a shortcut.
Of course, that is if we'd treat them the same.
If we create a loop with this syntax, does it invalidate the entire block?
If we were to work around such conditionals with inline ones, any IACVT variables used for that condition will result in everything inside becoming also IACVT.
Then, if we will have something like !revertable
(https://github.com/w3c/csswg-drafts/issues/10443) (and in some cases possible to work around today with revert-layer
(https://kizu.dev/layered-toggles/)), instead of completely nuking all the affected properties we could just fall back to the previous declarations.
Interestingly, only the element itself will be affected in this way: any nested styles could already be expressed as container queries, which properly handle reverting styles when not applying.
.foo {
--color: pink; /* becomes IACVT */
@element style(--color: pink) {
--color: not-pink;
& .bar {
background-color: pink;
}
}
}
In the above block, authors could separate the & .bar
into a container query, which could be cumbersome, but will work as intended. I don't think there is any other way it should behave for @element
, as there is no better behavior than just not applying styles similar to CQ here.
Thus, my proposal is: if an element query creates a loop in a condition, all affected styles on the element itself should be treated as !revertable
, and any nested styles should be treated as covered by the same container query.
Container queries allow us to query a container for specific conditions, including values of custom properties through
style()
queries.But they do not allow us to query the element itself.
In https://github.com/w3c/csswg-drafts/issues/10064 there is a proposal for inline conditions that do allow setting values conditionally when an element has a specific value. Implementers indicated that this would be possible
Can we have the same as an
at rule
?I am assuming that this needs to be highly restricted as explained in #10064 (only
style()
queries with custom properties?)This example would result in a
pink
background on any element with class.foo
when it also has--color: pink
.Nested vs. not nested gives interesting possibilities:
Benefits I see to this syntax: