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-cascade-5] What happens to name-defining @-rules nested inside @layer? #6404

Closed
andruud opened this issue Jun 22, 2021 · 5 comments
Closed

[css-cascade-5] What happens to name-defining @-rules nested inside @layer? #6404

andruud opened this issue Jun 22, 2021 · 5 comments
Labels
Closed Accepted by CSSWG Resolution css-cascade-5
Projects
Cascade 5 (Layers)

Comments

@andruud
Copy link
Member

andruud commented Jun 22, 2021

For example, you might expect this to define a fancy animation, ignoring the plain one:

@layer plain fancy;

@layer fancy {
  @keyframes anim { /* ... fancy animation ... */ }
}

@layer plain {
  @keyframes anim { /* ... plain animation ... */ }
}

It might be weird if it defines a plain animation? So probably another reasonable behavior is to make name-defining things
(e.g. @keyframes, @property, @scroll-timeline, etc) parse errors if they appear inside @layer.

cc @mirisuzanne @xiaochengh
@mirisuzanne
Copy link
Contributor

What's the full list of @-rules we need to consider here? @font-face as well? Are there more? Is it best if we come to the same conclusion for all of them?

Do we know if people currently use source-order to override name-defining rules? I wonder how much that happens. I think layers can be used in many cases to make source-order less important, so if there's a strong existing use-case for re-defining/overriding these names already, then I'd lean towards applying the layer-order cascade to these rules.

@mirisuzanne mirisuzanne added this to To Consider in Cascade 5 (Layers) Jun 22, 2021
@SebastianZ
Copy link
Contributor

A full list of at-rules can be found at https://drafts.csswg.org/indexes/#at-rules. As far as I can see, the name-defining ones are these:

@color-profile
@container
@counter-style
@custom-media
@custom-selector
@font-face (through its font-family descriptor)
@font-palette-values
@keyframes
@layer (of course)
@property
@scroll-timeline

Sebastian

@mirisuzanne
Copy link
Contributor

Thanks, @SebastianZ

I think we can ignore a couple of those here:

  • @container queries can reference a named container, but doesn't actually define that name. The name can be used as often as desired, without impacting previous usage - so I don't think that one's an issue.
  • @layer already has a defined behavior for nesting.

For the rest, the main use-case I can imagine is dealing with third-party code: eg overriding the built-in font or animation or counters (etc) from a component library. Though I don't think that's terribly common right now, it is one of the primary use-cases for @layer, so I do like the idea of having support for it.

@mirisuzanne mirisuzanne moved this from To Consider to To Resolve in Cascade 5 (Layers) Jun 30, 2021
@w3c w3c deleted a comment from css-meeting-bot Jun 30, 2021
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed What happens to name-defining @-rules nested inside @layer?, and agreed to the following:

  • RESOLVED: Name-defining at-rules follow layer order for collision resolution, similar to specificity resolution.
The full IRC log of that discussion <Rossen_> topic: What happens to name-defining @-rules nested inside @layer?
<Rossen_> github: https://github.com//issues/6404
<TabAtkins> miriam: Would something like @Keyframes, a name-defining at-rule, work in @layer and how?
<TabAtkins> miriam: If there are two @Keyframes with the same name, the later one wins.
<TabAtkins> miriam: Not common to do intentionally, but I did find some people using this to test out new animations live in production.
<TabAtkins> miriam: So question is if the two are defined in seaprate layers, does the layer order impact name collision reoslution?
<TabAtkins> miriam: I'd like to say yes, I think that's author expectation.
<TabAtkins> q+
<bkardell_> ScribeNick: bkardell_
<bkardell_> TabAtkins: I agree with Mia - It would rule out a lot of use cases and would be very confusing if pure source order applied to these rules
<bkardell_> TabAtkins: the whole point of layering is against that - I think name definiing rules should follow layer order just the same as anything else
<TabAtkins> ScribeNick: TabAtkins
<TabAtkins> Rossen_: Other opinions?
<TabAtkins> Rossen_: Not hearing objections, so let's resolve.
<TabAtkins> RESOLVED: Name-defining at-rules follow layer order for collision resolution, similar to specificity resolution.

@mozilla-apprentice mozilla-apprentice mentioned this issue Jun 30, 2021
Open
@mirisuzanne mirisuzanne moved this from To Resolve to To Draft in Cascade 5 (Layers) Jun 30, 2021
@mirisuzanne
Copy link
Contributor

Closed by a310957

@mirisuzanne mirisuzanne moved this from To Draft to To Review/Publish in Cascade 5 (Layers) Jun 30, 2021
@xiaochengh xiaochengh mentioned this issue Jul 19, 2021
Closed
@mirisuzanne mirisuzanne moved this from To Review/Publish to Complete in Cascade 5 (Layers) Sep 1, 2021
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-cascade-5
Projects
Cascade 5 (Layers)
Complete
Milestone
No milestone
Development

No branches or pull requests
5 participants
@andruud @mirisuzanne @lilles @SebastianZ @css-meeting-bot