- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 9 Jul 2012 13:34:12 -0700
- 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 UTC