[whatwg] Suggestion: Event-source to be DOM based rather than an HTML element

[Rohan Prabhu]

Dear Sir/Madam,
 I am writing this mail because I've recently studied your Web Applications
1.0 specifications, and have found a rather strange point in it. As the
'event-source' element is embedded in the Markup itself, it makes little
sense. It is for the simple reason that, assuming there be more than one
event-source handlers, then one has to be defined first and another one,
next. In that case, there is no significance of the order in which the
'even-source' elements appear. Here are my suggestion:

SEMANTIC PROBLEMS

In HTML, or any markup for that purpose, the order of elements has a special
significance. As for example, if there are two <p> tags, then th once coming
first is rendered first in the inline display and the one coming next is
displayed next (the relative positioning can be changed using CSS is a
different matter, however).

HTML as such is a static language (without a scripting backend). Hence,
dynamic elements within the flow of an HTML element, isn't proper semantics.

SUGGESTION (CLIENT SCRIPTING OBJECT)

To keep the semantics in place, I'd recommend that that the event-source be
rather specified as a JavaScript/DHTML object, just as the XMLHttpRequest
object is. A major part of event-source seems to fulfill the the
shortcomings of XMLHttpRequest object. In the same way the object
'event-source' can have following methods/properties:

Property: src (same as for the HTML element)
Method: connect (initiate the initial connection)
Method: disconnect (disconnect the connection or abort)
Property: onrecieve (function call. execute function when data is recieved)

ADVANTAGES (BANDWIDTH LOAD REDUCTION)

At the same time, this method also will enable developers to reduce the
bandwidth load on both sides by allowing the script to initiate and abort
the connection as and when required. There are various probelms when doing
so with an HTML element.

ADVANTAGES(COMPATIBILITY)

On top of it, it is more backword compatible than the HTML method. A simple
check (with client scripting) would be:

window.eventSource

In case JavaScript/Browser scripting is disabled, nothing would ever be
executed and event-source can't really be used without a Client-scripting
technology.

There is no way to check it using HTML methods, and if we were to specify
one, we still lose support of all the browsers that exist as of now. At the
same time, older browsers may not recognize the event-source element and
display something that would either obstruct the flow of the document or it
may abruptly quit.

ADVANTAGES(ADHERENCE TO EXISTING STANDARDS)

Also, if it is completely scripting based, it can even be validated using
current W3 validation services. (Since WHATWG currently doesn't have a
validation service, more developers will be encouraged if they can use
existing DTDs while at the same time using new technologies)

This is just a suggestion and hence I haven't worked much on it, but am
ready to contribute more inputs, once this suggestion finds higher
attention. I hope to hear from your side.

Rohan Prabhu,
Vadodara,
India

-- 
{Ro}h(a)[n]_-_[P]{rab}(h)u
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20061024/d37b2a34/attachment.htm>