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

[andruud]

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]

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.

[SebastianZ]

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]

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.

[css-meeting-bot]

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.

[mirisuzanne]

Closed by a310957