Re: [DOM-Events] General thoughts on DOM-Events (Editor's Draft 20 July 2009)

Hi, Sergey-

I'll reply with my opinion.  Though I'm the current editor of DOM3 
Events, I don't think I have the final say, and welcome consensus from 
the WebApps WG (and the larger community).

Sergey Ilinsky wrote (on 7/20/09 7:05 AM):
> I would like to bring to your consideration a concern that I've been
> bothered with for a longer time.
>
> Unlike DOM-Core (and other DOM specs), the DOM-Events specification
> seem to be concerned to much with a web-browser/HTML, which is not
> what [I think] it should do.

I don't think it's unreasonable to have the DOM3 Events spec reflect the 
current behavior of browsers.  The most recent DOM Core Recommendation 
is 5 years old, and it's been a busy five years in browser development.

Certainly there are other potential user agents, but how different are 
they that they should require changes in the spec?  Which other 
implementations are you specifically thinking of?

I don't agree that this spec is tied particularly closely to HTML, per 
se.  In fact, I personally focus much more on SVG than I do HTML.  What 
aspects of it do you think are too tied to HTML?


>The recent modification of the event
> flow (introduction of the defaultView to the even propagation path)
> brings it even closer there and in fact tightens it fast.

The DOM3 Events spec doesn't require that implementations put 
defaultView/window in the propagation path, only that they do so if 
defaultView implements the EventTarget interface.  This reflects what 
(at least) browsers do... what's the problem with that?  Where should 
that be defined, if not DOM3 Events?



> However, even in that effort, the DOM-Events specification is not
> expected to succeed. There is already drag-and-drop, state and other
> modules specified separately in HTML5. There are new events in
> CSS3-transitions coming and more.

There are events defined in SVG, as well.  The DOM3 Events spec 
explicitly states that it is not the sole or comprehensive place for 
event types and interfaces to be defined, but it is expected that those 
events it does define are more or less universal.


> So, would not it be more wise (future-proof) to take UI-related stuff
> away from the DOM-Events now and move it to HTML, or an other new
> specification?

If there is a future need for a different specification, we can write 
that specification then.


> The DOM-Events would preserve: 1) DOM Event architecture (flow,
> propagation, concepts of default actions etc.) 2) Event interface and
> extension model, that would allow defining other interfaces in other
> specs 3) DocumentEvent/EventTarget/EventListener interfaces 4)
> MutationEvent/MutationNameEvent interfaces and events
>
> The other specification would get the rest.

What would the pragmatic benefit of that be?  In my experience, 
splitting up the spec would take longer for each part to reach 
Recommendation, and I don't understand what you believe we would 
accomplish by that?

In particular, we have all the major browser projects committed to 
implementing this spec, and I for one want the keyboard events to be 
consistent across browsers.  Splitting the spec now would put that at risk.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 20 July 2009 23:35:05 UTC