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.

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

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

andruud opened this issue Jun 22, 2021 · 5 comments


Copy link

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

Copy link

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.

Copy link

A full list of at-rules can be found at As far as I can see, the name-defining ones are these:

@font-face (through its font-family descriptor)
@layer (of course)


Copy link

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

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:
<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.

Copy link

Closed by a310957

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

No branches or pull requests

5 participants