Re: [css-variables] fallback value handling needs better definition

On Tue, Feb 26, 2013 at 7:15 PM, John Daggett <jdaggett@mozilla.com> wrote:
> The current ED of CSS Variables defines syntax for a fallback value [1].
> It defines the use of the fallback value this way:
>
>   If the variable named by the first argument is valid, the
>   variable's value is substituted as normal. If it's invalid, and
>   a <fallback> was provided, the <fallback> is substituted
>   instead. Otherwise, the variable is an invalid variable.
>
> Does this mean that undefined variables cause the <fallback> to be substituted?

Other text in that section defines that undefined variables are
invalid.  (Or rather, that all variables implicitly have an invalid
value unless they're specified otherwise.)

> What's the exact way that a variable is determined to be "valid"?

When it's not invalid.  The spec defines only two cases that cause a
variable to be invalid - initially, and if the custom property that
grants it its value is invalid.  Custom properties are invalid if they
contain a cycle.

>  Simply that
> the resulting property value expression doesn't parse?  What happens when
> several variables are combined and the resulting combined expression is invalid?
> Are all fallback values used or is there some iterative process?

The spec defines that the fallback in a variable function is used when
the variable in the first argument is invalid.  It doesn't define any
other conditions, so nothing else causes the fallback to be used.

> :root {
>   var-x1: underline;
>   var-x2: underline;
>   var-x3: overline;
> }
>
> div.test2 {
>   text-decoration: var(x1, var(x3)) var(x2, var(x3));
> }
>
> text-decoration: underline underline; ==> invalid (i.e. x1 & x2)
> text-decoration: overline underline;  ==> valid   (i.e. x3 & x2)
> text-decoration: overline overline;   ==> invalid (i.e. x3 & x3)

None of the variables in this example are invalid, so the first
possibility is what occurs.  That causes the *text-decoration
property* to be invalid at computed-value time, but that has no effect
on the variables being used.

> Next, what happens when fallback values are nested?

They're processed as normal until a value emerges.

> div.test3 {
>   text-decoration: var(x1, var(x3, var(x1))) var(x2, var(x3));
> }
>
> Will the resulting value of text-decoration be valid?  Given nesting level n,
> does the user agent continue evaluating the expression n times until it finds
> one that is valid?

It has no effect on text-decoration, because the variables are all
valid, as I stated before.  However, if x1 and x3 were both invalid
variables, then the first variable would try to resolve to its
fallback "var(x3, var(x1))", which would then try to resolve to *its*
fallback "var(x1)", which would then make the property invalid at
computed-value time.

> In other words, do the evaluated expressions look like this:
>
> 1. text-decoration: underline underline; ==> invalid (i.e. x1 & x2)
> 2. text-decoration: overline overline;   ==> invalid (i.e. x3 & x3)
> 3. text-decoration: underline overline;  ==> valid   (i.e. x1 & x3)
>
> I think the definition of "valid" here needs to be more rigorously
> specified, especially given that the notation allows for nested
> fallback values.

The terms used here are very rigorously defined.  You're just reading
things that aren't there. ^_^  Use the spec's definition of all the
terms, not an English definition, as the latter will lead you astray
(as there are several things that can be invalid, with different
effects).

~TJ

Received on Wednesday, 27 February 2013 07:02:40 UTC