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. That said, I don't think that reason is at all compelling. As far as any list of features to cut (spin into other specifications) goes, I would rate this one fairly high on it, particularly if the element API were scrapped in favor of a pure-script API. There are interactions with the current task-queueing mechanism in HTML5, to be sure, but eventsource is mostly a consumer of those mechanisms, not a contributory component of it. I don't think eventsource's removal would affect the continuing evolution of the queueing mechanism in any meaningful way. Jeff
