Re: [css-variables] Editorial comments

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