Closed andruud closed 3 years ago
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.
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
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.
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.
Closed by a31095710
For example, you might expect this to define a fancy animation, ignoring the plain one:
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