- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Tue, 15 Jul 2025 22:13:16 +0000
- To: public-css-archive@w3.org
> Do `@layer` rules inside mixins affect the layer order? > Or only when those mixins are applied? Hmm, that's an interesting question. We do want to allow `@layer` rules inside of mixins, to put styles into particular layers, but having it also add to the layer order is a bit of an issue. We'd clearly have to do it as a *second phase*, to avoid weird circularity issues, and I think that means any new layers would just have to go to the end if they weren't already placed, in some sort of arbitrary order. There's also the question of whether `@layer` inside of `@mixin` cares about the `@layer` *outside* of the mixin. That is, in `@layer --foo { @mixin --bar { @layer --baz {...}}}` are those inner styles just in the `--baz` layer, or in the `--foo.--baz` layer? I think the answer is that it should ignore the outer layer - that puts the *mixin definition* into a particular layer, but you want the *evaluated results* to be in whatever layer the style rule it's substituted into is in (or a sub-layer of that, if the mixin is using layers in its body). This implies that `@layer` inside of a mixin can potentially have *multiple* effects on layer order, if the mixin is invoked in multiple locations across different layers. ----- This all gets a lot simpler if we just don't allow `@mixin` to be used inside of `@layer`, fwiw. Then we can say that mixins are substituted before layers are applied, then whatever you get post-resolution has the normal layer effects. The only alternative, I think, is to explicitly do a two-phase layer resolution - resolve layer ordering once, before mixins are applied, solely to determine how to resolve `@mixin` rule collisions, then again after all mixins have been applied, which can result in a *completely different* order. That might be really confusing... For example: ```css .foo { @apply --bar; } @layer a, b; @layer a { @mixin --bar {}; } @layer b { @mixin --bar { @layer b, a; } } ``` Before substitution, the layer order is clearly `a, b`. But after substitution, this is equivalent to: ```css .foo { @layer b, a; } @layer a, b; ... ``` And the layer order becomes `b, a`, since that new `@layer` rule precedes the previous one. Alternately, the second pass is only allowed to append to existing layer lists (aka all it can do is add *new* layers, not reorder anything), so the above doesn't change the layer order at all. This is probably more understandable overall, and any *questions* about it can be easily answered by just saying that you should pre-declare your layers anyway. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12417#issuecomment-3075907294 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 July 2025 22:13:17 UTC