- From: John Daggett <jdaggett@mozilla.com>
- Date: Wed, 27 Feb 2013 05:19:55 -0800 (PST)
- To: www-style list <www-style@w3.org>
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