- From: Stéphane Sire <sire@intuilab.com>
- Date: Wed, 5 Apr 2006 11:12:05 +0200
- To: public-webapi@w3.org
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
Received on Wednesday, 5 April 2006 09:12:25 UTC