W3C home > Mailing lists > Public > www-style@w3.org > July 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 9 Jul 2012 13:34:12 -0700
Message-ID: <CAAWBYDA4oEYVWj3GAzcPZsTiK3B8CeuVC1qLrez_Mx0g4bk=EA@mail.gmail.com>
To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
Cc: WWW Style <www-style@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:56 GMT