Re: [csswg-drafts] [css-mixins-1] Alternatives to using a scoping rule (#13727)

Yeah, the issue is that we *want* to resolve arguments immediately. Every programming language *in the world* resolves their arguments before evaluating their body. We can't *quite* do that, but we can fake it *really close* if the argument has a type, but only via the exact mechanism in the spec

```
@mixin --whatever(--arg <length>) { ... }
div {
  font-size: 10px;
  @apply --whatever(10em); /* if this doesn't make --arg 100px, it's broken, straight up */
}
```

Now to be clear, we *are* faking it. As Anders said, the mixin itself is resolved during stylesheet-building time, but the values need to wait until style-application time to know how to resolve. It's thus *fundamentally* impossible to "correctly" resolve the arguments before evaluating the body; like, logically impossible to do so. But, if they're typed, then storing them as (typed) custom properties on the applying element and using scoping + hygienic rewriting to let them safely inherit means we can fake it *extremely* well.

This is *also* why we can't automatically lift the arguments *higher* - not one level, not to the root. If we lift higher than the applying element, then the element-relative values resolve on the lifted element, not the applying element. That's *dramatically* worse than any of the other behaviors! Or, as I said in the call, we have to invent a *dramatically* new behavior that somehow avoids cycles while letting an ancestor resolve values based on a descendant's styles.

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


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

Received on Thursday, 26 March 2026 00:24:38 UTC