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

(12/07/10 1:35), Tab Atkins Jr. wrote:
> Apologies, the LC issues list is out-of-date.  For a response it
> should point to the minutes of the Hamburg meeting where this was
> re-discussed and we decided not to punt cycle() (and rename it to
> toggle()).
> 
> However, it was changed to Rejected status after the Hamburg meeting.

Okay, that makes more sense now.

>>> 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.


You can say this is a theoretical concern, but I would hope all CSS
specs follow this rather simple principle: no ambiguous formal syntax.

As a reminder, the recent 'font-family' example shows how syntax
ambiguity is bound for implementation discrepancy. (Tough admittedly,
the chances that this very case leads to incompatibility is close to zero.)

> 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.

I am afraid that how this is described in just... vague (i.e. I can't
find a sentence corresponding to "we define that a trailing argument can
contain commas itself"). I wouldn't be very surprised if there's an
implementation which just treats comma in <fallback> as invalid.... as
there's no example about comma in <fallback> either.

> and then we craft the syntax very carefully to prevent it from being
> ambiguous (usually, by freezing the number of comma-separated
> arguments)


Cheers,
Kenny

Received on Monday, 9 July 2012 18:22:35 UTC