[css-properties-values-api] [css-variables] Should the spec document invalid variables and fallback more explicitly?

[ghost]

Specs:
CSS Properties and Values: https://drafts.css-houdini.org/css-properties-values-api/#dependency-cycles-via-relative-units
CSS Variables: https://drafts.csswg.org/css-variables/#invalid-variables

Related spec bugs:
#821

Chromium recently changed their behaviour for fallback of registered custom properties (web-platform-tests/wpt#14039).

It seems to me that the spec is not clear enough about when values should act as initial vs unset. For example, in Chromium, if an unregistered property has a cycle, it is reset to its initial (known-invalid) value. If that variable is registered, it is set to an invalid value regardless of its initial value or its parent's value.

If an undefined or invalid variable is substituted into a property, it is treated as unset. Unless that property is a registered custom property, in which case it is treated as unset but when substituting it, it seems to act like invalid. Relative dependency cycles are treated as unset, however.

Here is a fiddle to demonstrate: https://jsfiddle.net/nzyfu1td/13/. This might be Chrome-specific and I am probably missing something here, but I think it would be nice if the spec could clarify all of these cases explicitly.

[andruud]

What I find confusing, is that CSS Variables currently use the term "initial" to mean invalid-for-substitution-value. This is of course because the initial value for unregistered custom properties always is the invalid-for-substitution-value, but it becomes confusing when the initial value can be something else.

Should probably go through CSS Variables, and make sure that it consistently uses the term "unset" when it means unset (i.e. invalid-for-substitution-value for unregistered properties, initial for non-inherited registered properties, and inherit for inherited registered properties), and "invalid value for substitution" (or something) when that's the intent.

[FremyCompany]

+1

[andruud]

@justinmichaud-2 The distinction between invalid at computed-value time and cyclic at computed-value time was added to css-variables a while back. In additions, all browsers have now shipped a consistent behavior for treating IACVT as 'unset' in all cases (see w3c/csswg-drafts#4075). Is this good enough to close this issue?