- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 10 Jun 2013 17:11:54 -0700
- To: Simon Sapin <simon.sapin@exyr.org>
- Cc: www-style <www-style@w3.org>
On Sun, Jun 9, 2013 at 7:54 AM, Simon Sapin <simon.sapin@exyr.org> wrote: > In the prose description of what the value of Custom Properties can be: add > that it can not be empty. In other words, this declaration is invalid and > ignored: > > var-foo:; > > However, per the current ED, this is valid since the value contains a > whitespace token. Do we want to keep it valid, or should "empty" not > consider whitespace? > > var-foo: ; Correct. I've added a note pointing this out. I think this behavior is desirable - it's useful to have variables whose value is "nothing". Within property values, whitespace is almost never significant, so using it as a "nothing" value is appropriate. > There should be a note that because of the general CSS parsing rules and the > restrictions on custom property declarations, a variable can not contain an > unbalanced quote, parenthesis or bracket: > > * A opening character causes the parser to not close the declaration until > it finds the matching closing character. > * An unmatched closing character is an error and causes the declaration to > be invalid and not set the variable. > > Using var() is therefore "safe" with respect to block nesting. Done. > Section 3: The <fallback> grammar in the definition of var() should be > renamed something like <variable-value> and be used in the Value line of > custom properties, to avoid repeating the definition and show that the > syntax is meant to be the same. > > In particular, we’ll want to explicitly disallow "top-level" semicolons in > <fallback> for the same reason we do in custom properties (even when it does > not terminate the value, eg. in the OM’s setProperty() method.) That is, we > don’t want computed values that are not serializable in a style rule. > > > The <fallback> value is identical to the syntax of a > custom property value: it accepts anything allowed by > the core syntax of CSS > (except that, since it's a value in a function rather than > a value in a declaration, some tokens that were allowed > in a custom property don't work in a <fallback> > and vice versa, because they'd close the function early). > > Given the above, the part in parenthesis is not necessary anymore. Done. I just switched it to use <any-value>, same as custom properties, and referred to it consistently as a "fallback value" (no production-angles). > The two paragraphs before section 3.1 seem to be an introduction to var()’s > fallback that was just defined. Perhaps they need to be moved earlier? Removed - the example about fallback values now talks about this better. ~TJ
Received on Tuesday, 11 June 2013 00:12:44 UTC