If we look at http://www.whatwg.org/specs/web-apps/current-work/#selectionmode we'll see the following IDL of SelectionMode

enum SelectionMode {
  // ...
  'preserve',
};

This is not allowed according to WebIDL http://dev.w3.org/2006/webapi/WebIDL/

Let's look why:

The nonterminal EnumValueList (what is between the { }) is defined (using EnumValues) as

[21]	EnumValueList	→	string EnumValues
[22]	EnumValues	→	"," string EnumValues 
 | ε

Thus if there is a comma a string has to follow. This string 'preserve' (which is also an invalid string according to WebIDL since string terminals have to be enclosed in double quotes - see bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=17507 - but this shall not mind here) is followed by a comma - but not by an additional string.

Thus we either have to change the WebIDL rules such that there is no need for a string after a comma or fix this IDL fragment by removing the , after 'preserve'.

This bug was cloned to create bug 18234 as part of operation convergence.

I think we should just fix Web IDL.

Sorry, the trailing comma look pretty ugly to me.

I've opened a more general and detailed bug here:
Bug 22156 - Allow trailing commas in Web IDL lists

To address your concerns Cameron, I think this is primarily about vertical lists and computer-generated lists, and secondarily about individual tastes.

I agree that the horizontal list {"foo", "bar",} is pretty ugly,
but OTOH in a vertical list, the form with trailing commas:
{
  "foo",
  "bar",
}
...looks clearer than the form without:
{
  "foo",
  "bar"
}
...and it's easier to edit when there are trailing commas (since don't need to add or remove when last element changes or moves).

It's also of course easier to generate for computer output or pretty-printing, since you don't need to special-case the last element, and as discussed in Bug 22156, trailing commas allow clearer diffs, and not allowing trailing commas is a comma source of syntax errors. Further many parsers allow trailing commas anyway (notably non-IE ES3 parsers -- a common cause of errors there -- and existing Blink IDL parser, which I'm in the middle of fixing). Also some developers really prefer trailing commas (for varied personal reasons).

So allowing trailing commas sounds like it would avoid a holy war (accommodating either style), avoid errors, and save developer time worrying about this -- it's a very easy mistake to make, so making the grammar more robust seems advisable.

What do you think?

I disagree about it looking clearer, but I relent.

http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.662;r2=1.663;f=h
http://dev.w3.org/cvsweb/2006/webapi/WebIDL/v1.xml.diff?r1=1.102;r2=1.103;f=h

*** Bug 21589 has been marked as a duplicate of this bug. ***

Thanks Cameron!

One tweak: the latest spec uses 4 rules:
Enum                → "enum" identifier "{" EnumValueList "}" ";"
EnumValueList       → string EnumValueListComma
EnumValueListComma  → "," EnumValueListString 
                      | ε
EnumValueListString → string EnumValueListComma 
                      | ε

...though we could instead use these 3 rules, which seem a bit simpler:
Enum          → "enum" identifier "{" EnumValueList "}" ";"
EnumValueList → string EnumValues
EnumValues    → "," string EnumValues
                | ","
                | ε

WDYT?

(In reply to comment #8)
> ...though we could instead use these 3 rules, which seem a bit simpler:
> Enum          → "enum" identifier "{" EnumValueList "}" ";"
> EnumValueList → string EnumValues
> EnumValues    → "," string EnumValues
>                 | ","
>                 | ε
> 
> WDYT?

That's not LL(1), since you can't decide which of the first two productions of EnumValues to take without looking ahead another token.  I'd like to keep the language LL(1) to make it easy to write a parser for.

(In reply to comment #9)
> (In reply to comment #8)
> > ...though we could instead use these 3 rules, which seem a bit simpler:
> > Enum          → "enum" identifier "{" EnumValueList "}" ";"
> > EnumValueList → string EnumValues
> > EnumValues    → "," string EnumValues
> >                 | ","
> >                 | ε
> > 
> > WDYT?
> 
> That's not LL(1), since you can't decide which of the first two productions
> of EnumValues to take without looking ahead another token.  I'd like to keep
> the language LL(1) to make it easy to write a parser for.

Got it, thanks for the explanation!
Right, it's LL(2); been using LALR parser so didn't notice.