[whatwg] Detailed review of "Interpreting an event stream"

[Henry Mason]

Hey all-

I've been working on an implementation of Server-Sent DOM Events. I  
ran into a small inconsistency in the specifications as they stand.  
Under section 6.2.4's "Class field" part:

     If the Namespace is null and the Event field is message (including
     if it was not specified explicitly), then the MessageEvent  
interface
     must be used.
     Otherwise, the Event interface must be used.

I feel this should be changed and simplified to to:

     Otherwise, the MessageEvent interface must be used.

Consider the following event stream (borrowed from Opera's sample  
code http://labs.opera.com/news/2006/09/01/ )

     Event: the-answer
     data: 42

As the spec currently stands, this will be interpreted as an event  
which uses the Event interface, since the Event field is neither a  
known DOM event type or message. However, since the specification  
currently says:

     If a field does not match any of the attributes on the event, it  
must be ignored.

The data field will be ignored, since the Event interface does not  
have an attribute named data. In order to get the behavior wanted  
here, you'd need to add a "Class: MessageEvent" field to the event  
stream.

Opera 9.x already seems to implement this feature such that their  
sample code works, so I'm presuming they're not doing it as its  
specified in the spec.

Since section 6.1 of the spec already says:

     Messages in cross-document messaging and, by default, in server- 
sent DOM events, use the message event.

...it is not very consistent to make the default behavior change to a  
different default behavior whenever the Event field is specified.  
Most authors sending simple events probably don't want to have to  
explicitly specify that the event they are sending is a MessageEvent,  
and requiring it is almost sure to lead to confusion.

-Henry