Re: [csswg-drafts] [css-variables] Should `var(var(--x))` work? (#11144)

> This sounds awful, and likely a non-starter. But I also don't see why it's needed.

lol. Well, the requirements I'm trying to satisfy are, roughly in decreasing priority:

1. No easily observable change to current invalid var() behavior - if a custom property contains an invalid var(), and is then substituted into a real property with var(), either that real property should become IACVT (if there is no fallback), or it should trigger fallback (if there was some).
2. Moving arbitrary contents out of a substitution function into a custom property, and then using var() to sub it back into that substitution function, should work in all cases. (That is, behavior of an invalid or failed substitution function shouldn't depend on whether it's known to be in a `<declaration-value>` grammar or not.)
3. As much as possible, a busted substitution function should act similarly to a busted non-substitution function.
4. Existing custom properties holding non-CSS stuff should change *as little as possible* if we add a new substitution function matching something they contain, especially if they're now invalid per the new function's grammar.

There's many ways to satisfy (1), but I think (2) is a lot stricter, and (3)/(4) basically force the same requirements.

Let me rephrase the proposal a bit, maybe you'll like it better this way:

* Substitution is now defined to be recursive, rather than iterative; we resolve starting from the innermost and moving outward. (Rather than today's behavior, where all "active" substitution functions are top-level, and fallback can drop more substitution functions in which then have to be resolved as well.) We drop the grammar-checking of substitution functions at parse time *entirely* - they grammar-check themselves during resolution only.
* Whenever a substitution function is either grammatically invalid, or is valid but fails to substitute (say, it's a cyclic or animation-tainted `var()`) and doesn't have a fallback, it's replaced by a guaranteed-invalid value *that serializes to the same string as the entire original function*. (This changes the final "Otherwise" branch of the [substitution algo](https://drafts.csswg.org/css-values-5/#substitute-arbitrary-substitution-function).)
* The guaranteed-invalid value is, in fact, valid in `<declaration-value>` and similar "anything goes" grammars. This includes the grammar of universal-syntax custom properties; we remove the rule that explicitly makes them IACVT when there's a substitution failure. It continues to be invalid for all other grammars. (Basically it's a new type of token that just won't match any grammars except those wide ones.)
* We change [the substitution algo](https://drafts.csswg.org/css-values-5/#substitute-arbitrary-substitution-function) to allow `result` and `fallback` to contain guaranteed-invalid values: if there *is* a fallback, and result has a GIV, then we replace with the fallback; otherwise (either no fallback, or the result doesn't have a GIV) we replace with the result. A GIV otherwise doesn't influence substitution directly; *eventually* it'll get grammar-checked (either by a containing substitution function, or by the containing property) and cause something to fail. (This changes the first two branches of the [substitution algo](https://drafts.csswg.org/css-values-5/#substitute-arbitrary-substitution-function).)
* We similarly tweak the resolution algos (like [for `var()`](https://drafts.csswg.org/css-variables/#resolve-a-var-function)) to correctly interface with this.

 Specifically, `var()`'s resolution algo would become:
 
 1. Let |result| be the value of the [custom property](https://drafts.csswg.org/css-variables/#custom-property) named by the function’s first argument, on the element the function’s property is being applied to.
 2. Let |fallback| be the value of the function's second argument, if specified; otherwise, let |fallback| be nothing.
 3. If the [custom property](https://drafts.csswg.org/css-variables/#custom-property) named by the [var()](https://drafts.csswg.org/css-variables/#funcdef-var)’s first argument is [animation-tainted](https://drafts.csswg.org/css-variables/#animation-tainted), and the var() is being used in a property that is [not animatable](https://drafts.csswg.org/web-animations-1/#not-animatable), set result to the [guaranteed-invalid value](https://drafts.csswg.org/css-variables/#guaranteed-invalid-value).
 4. Result |result| and |fallback|.
 
 (Only step 2 changed a little bit, to make an unspecified fallback actually be missing.)

This does change the serialization of properties that include a failing substitution function; currently they're specified to be the empty string. We could probably special-case that to preserve the behavior specifically for serializing a custom property (while substitution continues using the actual values, which will serialize as a non-trivial string).

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


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

Received on Saturday, 9 November 2024 00:06:40 UTC