[whatwg] Question regarding event: in server-sent events

[Nicholas Zakas]

Just for my own understanding, what you're saying is:

1) Any event name in the stream must be a valid event name in that it must not have spaces, special characters, etc. (The wording in the spec made me think that it must be an event name that is listed in the DOM Events spec, such as click.)

2) When you define an custom event name, this still fires the message event with event.type set to the custom event name.

Are those correct?

-Nicholas
 
______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."
-----Original Message-----
From: Anne van Kesteren [mailto:annevk at opera.com] 
Sent: Friday, October 15, 2010 11:42 AM
To: whatwg at whatwg.org; Nicholas Zakas
Subject: Re: [whatwg] Question regarding event: in server-sent events

On Fri, 15 Oct 2010 20:34:14 +0200, Nicholas Zakas <nzakas at yahoo-inc.com>  
wrote:
> In reading through the spec, it looks like this is legal in the event  
> stream:
>
> event: foo
> data: bar
>
> And then processed as:
>
>>> If the event name buffer is not the empty string but is also not a  
>>> valid event type name, as defined by the DOM Events specification, set  
>>> the data  buffer and the event name buffer to the empty string and  
>>> abort these steps.
>
> If I'm reading this correctly, an event name of "foo" would fail this  
> step in the process and not cause a message event to be fired. However,  
> if the event name were for example "click", then this would be okay and  
> the following step would be taken:

"foo" is a valid event type name. This would only fail when  
Event.initEvent(event name buffer, ...) fails. It seems per the current  
draft of DOM Events that will be never so maybe this ought to be reworded  
some. But then DOM Events is not done yet so...


> 3)       Assuming I've understood the current spec correctly, what is  
> the use case for named events?

To make dispatching to different parts of the code easier. Without having  
to create some kind of logic that parses the data first.


-- 
Anne van Kesteren
http://annevankesteren.nl/