Hi,
Here are just some simple thoughts to help to clarify the common
understanding of the event aliasing issue.
In my opinion the concept of event aliasing in the context of a
compound document answers to two different requirements. Let's imagine
a document belonging to a module X (for instance XHTML) that embeds a
document fragment belonging to a module Y (for instance SVG or SMIL):
module X
|--- module Y
In such a document event aliasing can be used:
1) inter-modules : to rename an event that "travels" between modules
(for instance during capture/bubbling phase, even if previous email
discussions didn't explicitely talked about the capture phase, it seems
to be part of the problem too)
2) intra-module : to give a synonym to an event name within the module
for backward compatibility
Concerning event listener registration with addEventListener a question
that CDF should answer is whether an event listener registered with a
target inside module X should be restricted to the event names known by
module X, or if it could register with other names aliases known in
module Y (inter-modules aliases). In my opinion the restriction should
apply.
For instance if an SVG module is hosted inside a SMIL module, an event
listener that registers to a target inside the SVG module should only
be able to register with an SVG event name (eg. DOMFocusIn or its
intra-module alias focusin) and reciprocally if the target is inside
the SMIL module (eg. focusInEvent). Hence the event name should be
dependant on the module of the document fragment to which the target
belongs to.
So according to that reasoning a part of the CDF specifications
concerning events would be to indicate inter-modules aliases for each
(x, y) couple where x is a module embedded inside another module y (eg.
SVG inside XHTML).
To simplify DOM3EV, an extension of that principle would be to restrict
DOM3EV event specification to simply define a base set of event names
associated with a generic DOM module (ie. a kind of event name
esperanto), and the CDF specification would define how these generic
event names are translated into module dependant names inside each
other module (HTML, SVG, SMIL, XForms, etc). Of course this does not
resolve the question of the different handling behaviours of those
events in different modules regarding propagation policy (bubbling,
cancelability, default action, target)...
Stéphane Sire
---
Research engineer
http://www.intuilab.com/gallery
