[go: nahoru, domu]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
andruud opened this issue Nov 24, 2021 · 9 comments
Closed

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

andruud opened this issue Nov 24, 2021 · 9 comments
Labels
Closed Accepted by CSSWG Resolution css-contain-3
Projects
Container Queries [css-contain] December 8 meeting December 15 meeting

Comments

@andruud
Copy link
Member
andruud commented Nov 24, 2021

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
Copy link
Member
lilles commented Nov 24, 2021

@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
Copy link
Member

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
Copy link
Contributor

I agree with that approach

@astearns astearns added this to Temp in December 8 meeting Dec 7, 2021
@astearns astearns moved this from Pubs and proposals to Temp2 in December 8 meeting Dec 7, 2021
@astearns astearns moved this from Top of priority list to Temp3 in December 8 meeting Dec 8, 2021
@atanassov atanassov added this to Can wait until 2022 in December 15 meeting Dec 15, 2021
@atanassov atanassov moved this from Can wait until 2022 to Everything else in December 15 meeting Dec 15, 2021
@atanassov atanassov moved this from Everything else to Can wait until 2022 in December 15 meeting Dec 15, 2021
@andruud andruud mentioned this issue Dec 16, 2021
Closed
@andruud
Copy link
Member Author
andruud commented Dec 16, 2021 •
edited
Loading

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

@css-meeting-bot
Copy link
Member

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

@mozilla-apprentice mozilla-apprentice mentioned this issue Jan 6, 2022
Open
@bramus
Copy link
Contributor
bramus commented Jan 7, 2022

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

@tabatkins
Copy link
Member

That's a reasonable interpretation, yes.

@mirisuzanne mirisuzanne moved this from In progress to Needs Edits in Container Queries [css-contain] Feb 3, 2022
@mirisuzanne
Copy link
Contributor

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.

mirisuzanne added a commit that referenced this issue Feb 18, 2022
@mirisuzanne
[css-contain-3] Draft logic for global at-rules in container queries #…
79132ec 
…6827
@tabatkins
Copy link
Member

Correct.

@mirisuzanne mirisuzanne moved this from Needs Edits to Done in Container Queries [css-contain] Feb 18, 2022
This was referenced Sep 6, 2022
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-contain-3
Projects
Container Queries [css-contain]
Done
December 15 meeting
Can wait until 2022
December 8 meeting
Temp3
Milestone
No milestone
Development

No branches or pull requests
6 participants
@andruud @mirisuzanne @bramus @tabatkins @lilles @css-meeting-bot