w3c
[css-conditional][css-mixins][css-cascade] How should global at-rules work inside of "contextual conditionals" like `@container`?
Currently, global name-defining at-rules, like @font-face, are allowed inside of "contextually conditional" rules like @container or @scope (which depend on tree information to resolve), and we just ignore the conditional-ness and define them unconditionally, instead. This came up again for @mixin.
We want to be consistent across these similar rules, as much as possible. Is the current behavior (which wasn't intentionally designed, it's just what implementations happened to do) what we want to continue with? Or do we want to try and change things so that using these at-rules inside of contextual conditionals is invalid?
The main issue I see with making these things invalid is that we need to make sure they would continue to work when we expand features like with @import … scope(…) (https://github.com/w3c/csswg-drafts/issues/7348).
If something works on the root level of a stylesheet, and then we import it somewhere, and “wrap” with @media, @layer, or @scope, things inside should continue to work as if they were being imported as usual.
Yeah, discussion during the f2f leaned towards (a) continuing with the current practice of pretending that "contextual conditions" like @container were always true for things like this that live at "stylesheet scope", and (b) handling any non-contextual conditions and wrappers as normal, and letting the concepts defined by these "stylesheet scope" rules draw from the "most recent" defining instance (rather than trying to resolve a "globally consistent" value after all stylesheets have loaded).
I think we can Agenda+ this to resolve on the behavior for contextual conditional rules.
Sorry in advance if this isn't the right issue for this...
I think @mixin has the potential to address most of the styling flexibility issues that exist with Shadow DOM. A style in a shadowRoot would use :host { @apply --my-element-mixin(); } to opt-in to rules potentially defined in a containing scope (e.g. this example in Chrome Canary 144).
For cases where this kind of permissive styling is desired, one of the only concerns I have with this is that it's a bit cumbersome to apply conditional styling. You can use if but only for individual properties and the application site isn't available.
Using @container style(...) in conjunction with @mixin, with either nested in the other, seems viable to address this, at least from an authoring perspective .
The CSS Working Group just discussed [css-conditional][css-mixins][css-cascade] How should global at-rules work inside of "contextual conditionals" like `@container`?, and agreed to the following:
-
RESOLVED: Treat contextual conditionals as always true for global rules i.e. the condition doesn't affect the rule
The full IRC log of that discussion
<fantasai> TabAtkins: Question is, if you put a global name-defining at-rule like @font-face or @mixin, into a contextual conditional like @container, which is defined at tree level, what happens?<fantasai> TabAtkins: Right now browsers treat the condition as always true
<fantasai> TabAtkins: and I don't have a great reason to do any other behavior!
<fantasai> TabAtkins: so I propose adopting that officially -- for conditional rules that require tree information, like @condition, do allow global name-defining rules inside them, they are treated as always there
<romain> +1
<kizu> +1
<kbabbitt> fantasai: personally it seems a bit weird to treat it as always true
<kbabbitt> ... would have expected to treat it as always false
<kbabbitt> ... but if this feels intuitive to people like miriam, happy to defer
<romain> always true works well with at-import conditions
<fantasai> TabAtkins: Given always-true is established behavior, we'd have to worry about compat if we change to anything else
<kizu> q+
<flackr> q+
<romain> q+
<fantasai> miriam: I would have also expected always-false, but ok with this
<Rossen3> ack fantasai
<fantasai> miriam: either way it's teachable
<Rossen3> ack kizu
<fantasai> kizu: I think always-true is better for some cases, maybe not all
<flackr> +1
<romain> q-
<fantasai> kizu: My comment in issue was about @scope. When you have some stylesheet, it has global things, they apply, and you import the stylesheet but wrap it in scope, if it stops applying it would be bad
<fantasai> kizu: this is a bigger issue that we have a more namespacing thing such that you could conditionally wrap something like that
<fantasai> kizu: but for things that you could import, always true is better
<Rossen3> ack flackr
<fantasai> flackr: agreed, always true allows you to use at-defined names
<miriam> that argument makes sense to me
<fantasai> RESOLVED: Treat contextual conditionals as always true for global rules i.e. the condition doesn't affect the rule
<fantasai> +1, makes sense to me
