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

> > 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.

It is not unreasonable to have the DOM3 Events spec reflect the current behavior of browsers. However it is reasonable to keep great DOM API being abstract, that would also conform better to the goals outline in the specification abstract:

"This specification defines the Document Object Model Events Level 3, a generic platform- and language-neutral event system which allows registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event."

> 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?

There are not many examples I can come up with. Maybe a pure XML document represented in DOM used as a data storage. Here only Mutation Events would be required (as well as the Events core implementation) for several parties writing to that DOM. Another example is DOM implementation on server-side used to keep the state of client DOM being synchronized by the means of Mutation Events mechanisms.

> 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?

Good point. But buy saying HTML I also meant SVG as another User Interaction technology. However it is already clear that many of the events defined in DOM-Events now are not applicable to SVG DOM.

> > 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?

Well, I don't see the defaultView object being part of the DOM at all. Why should it be considered as such? It is just another object in the browser environment.

> > 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.

Specifications, IMHO, should not (and in fact usually do not) bother with "more or less universal" things.

There are many events [specified] that are not already available in the DOM-Events enabled UAs. Consider iPhone not having the bigger part of the Mouse/Keyboard events. Or MathML language where interactive UI is not enabled etc.

> > 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.

Not sure if I understand this reply...

> > 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?

The pragmatic benefit is that there would be solid base - DOM-Events specification that would define the core principles for events distribution and handling in DOM structures as well as Mutation module. Such a specification could be finalized quickly and would not require changes in future.

The UI Events specification would define events available in interaction-enabled UAs as we know them now. In a future when new kinds of interaction is enabled, the relevant updates would go into that specification without touching the base.

Another concern that you did not reply to - HTML5 will define new events and interfaces. Nut why those things should be separated there? Drag and Drop module events are "more than less" universal, so SVG would also benefit from them.

My appeal here is not to over complicate the standardization process, but to create a better technology framework. Hope I was clear.

Sergey Ilinsky/

Received on Wednesday, 22 July 2009 16:45:01 UTC