Re: [csswg-drafts] [css-mixins-1] Need a non-hacky way to force an element-dependent value on the applying element (#13454)

Dropping hygienic rewrites would make naming collisions more common, especially if the dev is using third-party libraries, and thus without hygienic rewrites, you'd kinda be forced to using naming conventions (BEM, etc) within mixins.

Personally, I'd like to recommend the first solution: Lifting Local Variables + Hygiene, because it's the most intuitive + it continues the current mental mode of how CSS units works (unlike the current draft), and it follows the frameworks' trend of trying to prevent leaky code.

But like Tab said, sometimes you do want the child’s context to matter. So, to fix that: rather than making everything leaky or nothing leaky, why not add a keyword/function to say "just make this one value leaky".

So... by default, the browser assumes all data is fixed/static and thus should be lifted, and it will only resolve against the target element if you explicitly say so.
Something like this:
```css
@mixin --card-logic() {
  --fixed-gap: 1em; /* 24px */

  @result {
    gap: var(--fixed-gap); /* 24px */
    padding: 1em; /* 24px */
    margin: local(1em); /* 24px */

    & > h1 {
      width: var(--fixed-gap); /* 24px (Captured) */
      padding: 1em; /* 24px (Captured via Lifting) */
      margin: local(1em); /* 32px (Not captured thanks to local()) */
    }
  }
}

main {
  font-size: 20px;

  section {
    font-size: 24px;
    @apply --card-logic();

    > h1 {
      font-size: 32px;
    }
  }
}
```
I'm not sure what to name this new function, here's what I've currently got: `self()`, `this()`, `local()`, `dynamic()`, `resolve()`, `context()`, `contextual()`.
Additionally, this new function would pair well with `var()` like: `margin: local(var(--size, 1em));`.
And, for clarity, only Font-relative and Container/Viewport units should be "lifted by default".

One potential issue is that since the browser can't pre-calculate all styles for all children & descendants at once, it would be technically slower than the current draft's proposal.
However, I'd argue that CSS already does this. So, it's not like the browser is doing "extra work", it's just doing the "normal work", rather than the "optimized work".

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


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

Received on Wednesday, 25 February 2026 17:38:01 UTC