[css-mixins-1] Need a non-hacky way to force an element-dependent value on the applying element

[tabatkins]

Due to hygienic renaming and the mixin evaluation rules, code like the following:

	@mixin --triple-border(--size <length>) {
		@result {
			&, & > *, & > * > * {
				width: var(--size);
				border-width: .2em;
			}
		}
	}
	section {
		font-size: 10px;
		--size: 10px;
		@apply --triple-border(10em);
	}
	section > h1 {
		font-size: 20px;
		--size: 20px;
	}
	section > h1 > small {
		font-size: 15px;
		--size: 15px;
	}

Will desugar to approximately:

	section {
		--f7bd60b7: 10em; /* and it's registered as a <length> so it turns into 100px here */
		font-size: 10px;
		--size: 10px;
		width: var(--f7bd60b7); /* 100px;*/
		border-width: .2em; /* 2px */
	}
	section > h1 {
		font-size: 20px;
		--size: 20px;
		width: var(--f7bd60b7); /* 100px */
		border-width: .2em; /* 4px; */
	}
	section > h1 > small {
		font-size: 15px;
		--size: 15px;
		width: var(--f7bd60b7); /* 100px */
		border-width: .2em; /* 3px */
	}

That is, the var() referencing a Mixin argument is captured on the applying element and maintains a single stable value across all uses, but the em length isn't touched, and resolves based on the element it's used on.

This isn't an undesirable behavior in general - it'll probably often be the case that you do indeed want the styles you put on children to resolve on the children. But I think it'll also be common to want to capture a value on the applying element and use that on the children, but right now the only way to do that is with an argument that you just document the user shouldn't pass, so you can set a default value, like:

	@mixin --triple-border(--size <length>, --em <length>: 1em) {
		@result {
			&, & > *, & > * > * {
				width: var(--size);
				border-width: .2--em;
			}
		}
	}
	section {
		font-size: 10px;
		@apply --triple-border(10em);
		/* Everybody gets a 100px width and a 2px border-width, using this element's font-size */
	}

That's awkward and clumsy, tho. You might think you could use a local variable with a type-coercing function, like this:

	@function --as-length(--x <length>) returns <length> { result: var(--x); }
	@mixin --triple-border(--size <length>) {
		--em <length>: --as-length(1em);
		@result {
			&, & > *, & > * > * {
				width: var(--size);
				border-width: .2--em;
			}
		}
	}

But that doesn't work. The evaluation rules lift that local variable into being a local variable in an anonymous function called on each element, and custom functions inherit font-size from the calling element, so the 1em will still be evaluated based on each element's local font-size instead.

---

There's a few possible solutions to this. I think the most obvious is to make local variables act exactly the same as Mixin parameters, and lift+hygiene them onto the applying element. We'd have to lift the entire Mixin body, tho, since the local variable might be set inside an @media. That means even more "unobservable" things on the applying rule, but perhaps that's fine once you've already bitten the bullet of having an unobservable custom property in the first place. (This would also make the "inside-out" and "outside-in" desugarings actually identical; see Example 20 at the end of https://drafts.csswg.org/css-mixins/#evaluating-mixins.)

If that's no good and we have to maintain the different behavior for parameters and locals, then we can at least add something "in-between" the two, which is lifted like a parameter but solely under author control like a local. That's right, we'd be reviving the using(...) clause, letting it add "shadow" parameters that are evaluated as if they were unpassed arguments, just resolving to their default value (which would be required in the grammar for the using-list).

I'd definitely prefer the first solution, tho, as locals and parameters are otherwise pretty identical. Thoughts? @andruud @emilio (I dunno who, if anyone, from WebKit is appropriate to ping for opinions on these issues)

[tabatkins]

I suppose another way around this would be to have the anonymous functions magically have their hypothetical elements inherit from the applying element, rather than their calling element. But that'll put us in the opposite situation and make all values evaluate based on applying element information; even the first example in my previous post would give consistent lengths to all three elements' borders. I don't think there'd be a workaround, either. That seems bad.

[andruud]

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

In this "most hygienic" model, the mixin body then approximately becomes an & rule, vending --magic-* properties:

@mixin --enhance(--x <number>, --y <number>) {
  --derived: 0;
  @container (...) {
    --derived: calc(var(--x) + var(--y));
  }
  @result {
    --out: var(--derived);
  }
}

=> (pseudo-css)

@mixin --enhance(--x <number>, --y <number>) {
  & { /*magic*/
    --magic-x <number>: /* argument to x */;
    --magic-y <number>: /* argument to y */;
    --magic-derived: 0;
    @container (...) {
      --magic-derived: calc(var(--x) + var(--y));
    }
  }
  @result {
    --out: var(--magic-derived);
  }
}

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?

[sesse]

FWIW, since nobody else has mentioned what I think is the most obvious solution: Drop hygienic rewrites altogether. :-) They require increasingly complicated layers of rewrites, they limit mixins to being scoped (I can imagine sibling selectors in particular being interesting to support), and there's no obvious way to have non-hygienic arguments should you want them. On the flip side, an author that actually wants hygienic variables can easily make them on their own without any help from the UA (just set a custom property). I think we need to balance how common these problems actually are against the amount of pain we're adding to the standard.

[TimChinye]

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:

@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".

[tabatkins]

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?