Re: [SVGMobile12] event aliasing

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

Received on Tuesday, 4 April 2006 17:04:01 UTC