[whatwg] <eventsource>/RemoteEventSource wierdness

Thu Feb 19 09:20:37 PST 2009

On Thu, Feb 19, 2009 at 3:10 AM, Jeff Walden <jwalden+whatwg at mit.edu> wrote:
> On 17.2.09 22:53, Jonas Sicking wrote:
>>
>> This could also replace the IMHO awkward<eventsource>  element. I
>> don't understand the value of having this element at all. It seems to
>> me that if the only way you can use an API is through script, then
>> making the API into an element is adding extra complexity to the HTML
>> language for little to no gain.
>
> I seem to recall reading once that it's not the case that the only way you
> can use the API is through script -- sort of.  At one time I believe the
> intent was that an onmessage attribute on <body> would allow you to have
> handlers without needing to run script to set them.  You would of course
> still need script to execute for the handler to run.

Exactly, it's the fact that you ultimately always have to forward to a
script to handle the event that I was referring to.

This isn't 100% true though. As I understand it, the idea is to allow
support for firing other event types than 'message', at which point I
*think* you could do things like trigger SMIL animations and run
XForms actions without resorting to javascript. However neither of
these things are practically supported by the spec now, so I don't
think that's an argument for keeping the current design.

And it still doesn't explain why you'd want addEventSource on
XMLHttpRequest, WebSocket or Window.

/ Jonas