- From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
- Date: Tue, 10 Jul 2012 08:57:50 +0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: WWW Style <www-style@w3.org>
(12/07/10 4:34), Tab Atkins Jr. wrote: >> 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? Yes, thanks. >>> 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. Before toggle() mentions that <value> can't contain comma, it's just not possibile to tell why <fallback> can contain comma and <value> can't, without looking at the note, which isn't part of the normative spec. Now that there a normative sentence backing up this difference, it's clearer now. But in general, we seem to have very different criteria about what makes a "definition". This is what happened: 1. You said "the only exception is when we define that a trailing argument can contain commas itself (such as in attr())" 2. Since you used the word "define" instead of "say", I expected that I could find a normative sentence about this in the description of attr(). 3. I found nothing, and hence the complaint. I would encourage CSS specs to go the side where everything is well-defined and reading it is as enjoyable as reading the HTML spec: full of definitions, hyperlinks and step-by-step algorithmic procedures. css3-syntax is close to this but css3-values is not. Cheers, Kenny
Received on Tuesday, 10 July 2012 00:58:16 UTC