Repository navigation
[css-cascade-5] What happens to name-defining @-rules nested inside @layer? #6404
Description
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.
Activity
mirisuzanne commentedon Jun 22, 2021
What's the full list of @-rules we need to consider here?
@font-faceas 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 commentedon Jun 22, 2021
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 itsfont-familydescriptor)@font-palette-values@keyframes@layer(of course)@property@scroll-timelineSebastian
mirisuzanne commentedon Jun 22, 2021
Thanks, @SebastianZ
I think we can ignore a couple of those here:
@containerqueries 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.@layeralready 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 commentedon Jun 30, 2021
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 commentedon Jun 30, 2021
Closed by a310957