Re: [csswg-drafts] [css-mixins-1] How are cycles broken? (#12595)

Provided that the `@apply` call takes place after the mixin is defined, I don't think I see how `--a()` can be invalid? 

Even in an order dependent world, this depends on which way https://github.com/w3c/csswg-drafts/issues/12670 goes:

1. If we bind `@apply` rules to their mixins "eagerly", as @kizu proposed. Then I don't think cycles can happen. At least not if we also say that a mixin does not exist (i.e. isn't visible) within itself, to avoid a self-cycle like `@mixin --a() { @apply --a(); }`. This seems like a good outcome for this issue.
2. Otherwise, if we bind `@apply` rules "dynamically" as originally envisioned ([a result of `violet`](https://github.com/w3c/csswg-drafts/issues/12670)), then we do need to pick between a result of `a` and `c` here. It seems unlikely that authors should care deeply about the exact error recovery behavior, so we should pick what is easier to implement: when attempting to apply a mixin which is _already on the apply stack above you_, that `@apply` rule is ignored. That would result in `--last-processed:c` in the original example.


-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12595#issuecomment-3527877517 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 November 2025 13:41:31 UTC