Actually I see DOM3EV as specifying some mechanisms and some policies
at the same time.
The mechanisms are the basic interface above which event propagation
and handling algorithms will be implemented. It's also the base
abstract data structures from which event classes will be derivated and
some ways to access event data. It also describe some concepts for
defining the control of the event propagation flow such as
capture/bubbling/cancel/default action...
The mechanisms have been described by Anne as follows:
> The events specification defines a set of interfaces to be
implemented and
> supported by UAs. These are Event, EventTarget, EventListener,
> EventException, EventExceptionCode, DocumentEvent and CustomEvent. UAs
> also need to support the event flow and all that.
The policies have been described by Anne as follows:
> It furthermore defines a set of events to be reused by other
> specifications. It defines the interfaces for those events, as well as
> some indiciation of their semantics and how they work, et cetera. For
UAs
> to be conforming with DOM3EV they won't have to implement these
events.
> Specifications trying to conform with DOM3EV have to define when these
> events are dispatched and how they interact with the language. For
> example, on which elements 'submit' can be dispatched.
The policies are the concrete event names and sub-classes (such as
UIEvents for mouse and wheel events, or mutation events), and the
nature of the event propagation flow for each of those concrete events
in a given language (ie. HTML, SVG, SMIL, etc). Some of the policies
are language independant (like mutation events) whether others are
language dependant.
It's up to us to decide whether the spec should limit itself to the
mechanisms and the language independant policies or if it should also
include the language dependant policies as mandatory.
In my opinion the language dependant policies should be specified
elsewhere, for instance in each specific recommendation (ie. HTML, SVG,
SMIL, etc.). At the best if we want to include language dependant event
specifications in DOM3EV it should be in the form on "canonical" event
names, data structures and propagation policies that would be
mentionned as beeing specific of the implementation language and
potentially modified from the canoncial form by each of those
languages.
To deal with compound documents, the CDF could define how the event
data and event propagation flow are altered when propagating a concrete
event to a parent fragment belonging to a different language. I called
this "inter-module" propagation in a previous email [1]. For instance,
if there are n languages, instead of defining 2*n*(n-1) adaptations
between each language types, a trick could be to define the adaptation
from each language to the "canonical" event forms defined in DOM3EV,
that would allow CDF to specify only n adaptations.
[1]
<http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0044.html>
Stéphane Sire
---
Research engineer
http://www.intuilab.com/gallery
