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

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-variables] Should `var(var(--x))` work? ==
The Variables spec is currently not entirely clear whether `var(var(--x))` is intended to work. As an example:

```css
.foo {
 --color: green;
 --var-name: --color;
 color: var(var(--var-name));
}
```

Should this be valid, resulting in `color: var(--color);`, and ultimately `color: green;`?

Chrome's implementation, iiuc, currently allows nested var() references only in the `<declaration-value>` part, because that chunk isn't interpreted at all - they're processed as part of fallback processing. Per Variables ([now Values](https://drafts.csswg.org/css-values-5/#arbitrary-substitution:~:text=and%20those%20functions%20are%20themselves%20syntactically%20valid)), you have to verify that the var() is syntactically valid at parse time; our engineers interpreted that as "you must fully satisfy the specified grammar". This isn't an unreasonable position, but it does mean we're slightly limited in how var() can be used.

The larger issue is that this has knock-on effects for other arbitrary-substitution functions. For example, in `if()`, if we apply the same criteria, it's allowed to use a `var()` in the *value* of a clause (which is a `<declaration-value>`, so a `var()` there just isn't interpreted at parse-time), but not as part of the *test* (which has a specific grammar); `--test: media(width < 600px); color: if(var(--test): green)` would be invalid. I think that's pretty surprising, and authors would run into it and complain.

So, I believe we should fix up the definition a bit to allow for nested var() delaying the syntax checking of outer var()s.

/cc @LeaVerou @andruud 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11144 using your GitHub account


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

Received on Friday, 1 November 2024 23:22:23 UTC