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

Tab Atkins 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.)

Ok, I see the problem.  The second sentence in the spec quote is
unclear, the problem is what "If it's invalid" refers to.  You intend
it to mean "If the variable is invalid.." but I read that as "If the
variable's value is invalid...".  The last sentence is sort of odd too,
since the paragraph is really defining the return value of var() that
uses a variable and not the variable itself.

Simple fix:

  If the variable named by the first argument is valid, the
  variable's value is substituted as normal. If the variable is
  invalid, and a <fallback> was provided, the <fallback> is
  substituted instead. Otherwise, the result of evaluating the
  var() function will mean that the containing declaration is
  invalid at computed-value time.

Also, the line above this paragraph reads:

  The <fallback> value is identical to the syntax of a custom property.

I think you mean "custom property *value*" instead of custom property.

So what is the use case that benefits from having a fallback value,
since it's basically only a fallback for undefined variables?  Seems
like unnecessary complexity for level 1.

Cheers,

John

Received on Wednesday, 27 February 2013 13:20:21 UTC