(In reply to comment #0)
> A serializer is supposed to be able to be:
> 
>    serializer identifier name();
> 
> But the syntax has that as serializer OperationRest. OperationRest does not
> include the identifier, so it needs to be added.

Of course I would be more readable if I were awake. I meant

    serializer type identifier();

The type is not accounted for in the syntax.

Maybe relatedly, the grammar prevents having a ";" (instead of mandating it) after an empty serializer declaration. 

interface Foo { serializer }; // valid according to the current grammar
interface Foo { serializer; }; // invalid according to the current grammar

The grammar also lacks support for the

  serializer = { attribute };

and

  serializer = { inherit, attribute };

variants.

I still claim the entire serializer setup is overengineered.  Does anyone really want anything other than { attribute } for interfaces with no ancestors that have serializers or { inherit, attribute } for ones that have such ancestors?

(In reply to Boris Zbarsky from comment #4)
> I still claim the entire serializer setup is overengineered.  Does anyone
> really want anything other than { attribute } for interfaces with no
> ancestors that have serializers or { inherit, attribute } for ones that have
> such ancestors?

In IE, we've only wanted (and implemented) this for the NavigationTiming [1] and related interfaces, in order to make it easy to package and serialize the attributes. +1 for potentially simplifying the grammar to remove use-cases until/unless we find a good reason for them.

[1] http://www.w3.org/TR/navigation-timing/#sec-navigation-timing-interface

In Gecko's case we use it for some of the timing stuff, but also for some WebRTC interfaces (RTCIceCandidate, RTCSessionDescription).  In any case, all those consumers want to serialize all the attributes.

Consolidating serializer issues into a simplification issue at https://github.com/heycam/webidl/issues/188