[css-contain-3] What happens to other @rules inside @container?

[andruud]

E.g. @property, @font-face, etc.

css-contain-3:

The @container rule is a conditional group rule [...]

css-conditional-3:

[about conditional group rules]: When the condition is true, CSS processors must apply the rules inside the group rule as though they were at the group rule’s location; [...]

However, that text in css-conditional-3 was probably written with the assumption that the condition can be evaluated parse-time. @container is more complicated than this, and can evaluate to both true and false depending on the element we're resolving style for. Maintaining a number of different @rule-realities dynamically per element is probably not a practical option.

For @layer we decided that it should impact layer order regardless of evaluation. Not sure if that translates into anything else.

cc @mirisuzanne @lilles

[lilles]

@font-face seems hard enough for shadow tree scopes. I don't think we would want to implement per element font caches. Are the options:

1. Drop the rule
2. Let the rule have no effect
3. Always have the rule take effect ignoring the container query

Others?

[tabatkins]

Agreed, the @container absolutely cannot affect the @font-face.

I'd prefer we stayed as consistent as possible if there's no good reason not to, so I suggest the @font-face (and similar rules) just always takes effect, aka treating the @container as always true.

[mirisuzanne]

I agree with that approach

[andruud]

Note: It may make sense to also consider #6895 while discussing this.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-3] What happens to other @rules inside @container?, and agreed to the following:

• RESOLVED: Property and fontface rules always work in an @container rule

The full IRC log of that discussion

<dael> Topic: [css-contain-3] What happens to other @rules inside @container?
<dael> github: https://github.com//issues/6827
<dael> miriam: Dealt with a version of this problem before
<dael> miriam: Containers don't have a global resolution. Specific to elements and contexts
<dael> miriam: Need to know if allowed and what happens to have global @rules like property or fontface inside @container
<dael> miriam: On thread agreed for these rules we think @container should be treated as true for all cases like these to be consisten with previous decisions
<dael> astearns: No difference in having @fontface inside or outside a container
<dael> miriam: Right
<dael> astearns: reasonable to me
<dael> TabAtkins: yep, agreed
<dael> dbaron: At first glance seems surprising. Are there other things that work this way?
<dael> astearns: Talked about layer order previously
<dael> miriam: Yeah, layer order. I feel like also some name defining @rules, but that's this so maybe we didn't. I think there was previous art on this
<dael> TabAtkins: Ultimately they're always true or false, we can't make them dependant on the query. The always true is consistent. But we oculd say it's always false if that's more reasonable.
<dael> dbaron: Curious why it's not syntax errors and drop. That was one of Rune's options
<dael> astearns: Would you like more time to consider and consult?
<dael> dbaron: If nobody else thinks it makes sense okay resolving. My intuition is if we don't know how to process it shouldn't be allowed
<dael> astearns: We can process fine. Slightly less surprising the rules don't disappear
<dael> dbaron: Maybe. Okay
<dael> astearns: We are at time. Prop: Property and fontface rules always work in an @container rule
<dael> miriam: Prior are was for @layer where @layer has no effect on name defining rules
<dael> s/are/art
<dael> astearns: Anyone want to chew on this more?
<dael> RESOLVED: Property and fontface rules always work in an @container rule

[bramus]

Following the decision above — and borrowing terminology from ECMAScript — one could say at-rules nested inside @​container get hoisted?

[tabatkins]

That's a reasonable interpretation, yes.

[mirisuzanne]

The resolution text here specifically mentions @property and @font-face, but my understanding is that this would be true for all name-defining at-rules, and wouldn't really be applicable to anything else. Is that an accurate understanding? Something like…

Global, name-defining [=at-rules=]
such as ''@keyframes'' or ''@font-face'' or ''@layer''
that are defined inside [=container queries=]
are not constrained by the [=container query=] conditions.