[css-variables] Invalid arbitrary substitution values as <declaration-value>

[cdoublev]

Is it ok that Chrome/FF do not accept var(--custom, var(--)) at parse time? I would have rather said it is invalid at computed value time.

var() = var( <custom-property-name> , <declaration-value>? )

https://w3c.github.io/csswg-drafts/css-variables-2/#using-variables

The <declaration-value> production matches any sequence of one or more tokens, so long as the sequence does not contain <bad-string-token>, <bad-url-token>, unmatched <)-token>, <]-token>, or <}-token>, or top-level <semicolon-token> tokens or <delim-token> tokens with a value of "!". It represents the entirety of what a valid declaration can have as its value.

https://w3c.github.io/csswg-drafts/css-syntax-3/#any-value

I guess they are recursively looking all var() in the input list of component values and validate their arguments.

[andruud]

Variables does say:

In addition, if the value of a custom property contains a var() reference, the var() reference must be valid according to the specified var() grammar. If not, the custom property is invalid and must be ignored.

But it's indeed not clear if this is intended to mean "direct" var() only, or if the rule also applies to "inner" var()s.

[cdoublev]

Yeah, I briefly described the problem but I think the spec should say that any existing var() should be valid.

An invalid var() is a valid <declaration-value> but the authors (and implementers, I guess) want it to be invalid.

[tabatkins]

Hm, indeed, I don't describe that well.

I don't think I had an intention in either direction, but thinking about it now, I do think it's good to validate the nested var()s, and luckily that's the interoperable behavior.