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

> So to clarify, local hygiene would would have to combined with --em: --as-length(...) and 0.2--em to get the desired effect here?

Yes. (Unless/until we add a way to declare the type of a custom property inline, like you've sketched in your code.)

> This means the `@container` effectively resolves against the `@apply`-element for any `var(--magic-derived)`, regardless of which element is targeted. That could be reasonable in this mode?

Yes. Putting the `@container` inside the mixin result will resolve on the appropriate element based on surrounding style rules, as usual, but I think it's completely reasonable for the mixin body to be consistently applied to the applying element. I think it would actually be confusing to have the opposite behavior.

> FWIW, since nobody else has mentioned what I think is the most obvious solution: Drop hygienic rewrites altogether. :-)

Macro systems without hygiene are *fundamentally broken*, as far as I'm concerned. (Yeah, the C preprocessor is ancient junk.) They always have to introduce *ad hoc* hygiene  mechanisms anyway, like a gensym for a guaranteed no-collision name. (But *using* those requires even heavier rewriting potential, actually outputting a token stream that'll get parsed into rules, rather than outputting a well-structured rule.)

"Escaping" hygiene is trivial - just reference a variable name that's not an arg/local. That's standard behavior for hygienic macro systems; you look for *captured* names and rewrite those, but leave uncaptured ones alone to let them reference the outside scope. You can also `inherit()` in the Mixin body; that looks outside the scope *explicitly* so it won't be rewritten (unless the *outer* scope is also a Mixin that's captured the name, in which case the capture/rewrite is very much intended).

(I don't think there's a use-case for allowing someone to request a name to be left unwritten even tho it's captured locally. You can just... rename your variables if that's a problem.) 

> Suggestion for a `local()` or similar

We already have a mechanism for this, fwiw. To get the value to *actually* resolve on the applying element, it needs a type: either an argument type, or wrapping a local's value in `--to-length()` (or whatever). If you don't do that, it's just an untyped custom property, not resolved in any way until it's actually substituted into a property, so relative values like `1em` will resolve on the individual elements, same as setting `--foo: 1em;` directly on an element and then referencing it in `width: calc(10 * var(--foo));` on children does today.

I think we can probably just document that as the technique for getting late-resolution for now, and revisit later if we do want something more explicit. Does that sound okay?

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


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

Received on Tuesday, 3 March 2026 17:29:10 UTC