Re: [css3-values][css-variables] definition of <value>

On Mon, Jul 9, 2012 at 11:22 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> wrote:
> (12/07/10 1:35), Tab Atkins Jr. wrote:
>>>> The note is just there as a reminder to authors.
>>>
>>> I always assume a spec would have the same normative meaning with all
>>> the notes removed. Am I just missing a normative statement somewhere?
>>
>> You aren't missing anything, there just isn't an ambiguity for
>> browsers.
>
> A formal syntax with ambiguous syntax should generally be avoided. An
> ambiguous syntax would make a parser generator give a warning, which is
> not a good thing.
>
> I am talking about this line:
>
>   toggle( <value># )
>
> , which is ambiguous if you don't normatively say <value> can't contain
> comma.

I've altered the definition of <value> to explicitly disallow
top-level commas.  Is the spec acceptable now?

>> Functions always split their arguments on commas.
>> "toggle(blue, white)" is two arguments, not a single "blue, white"
>> argument.  The only exception is when we define that a trailing
>> argument can contain commas itself (such as in attr()),
>
> So the prose has
>
>   # The optional <fallback> argument represents a fallback value, which
>   # is used if the named attribute is missing, or its value cannot be
>   # parsed into the given type or is invalid/out-of-range for the
>   # property. If it's absent, the default value for the given
>   # <type-or-unit> (from the list below) is implied.
>
> which doesn't explicitly say <fallback> can contain comma.

It's unnecessary to explicitly say that, any more than we need to
explicitly say it can contain spaces.

~TJ

Received on Monday, 9 July 2012 20:35:00 UTC