- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 19 Feb 2009 09:20:37 -0800
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
Received on Thursday, 19 February 2009 09:20:37 UTC