RE: [SVGMobile12] event aliasing

The double-dispatching approach that Anne suggests matches what I had in
mind for event aliasing on the dispatching side. As far as I can see,
the only thing that is different versus "event aliasing" is that
script-generated events via createEvent() would not be equivalenced, but
it is questionable whether one would even want such equivalencing.
Anne's approach also formally deprecates older events such as SVGLoad,
which I think is also a good idea. So, I would love it if there could be
a consensus around Anne's suggestion.

If people like Anne's approach, let's get into a few details:

* We would drop SVG-t 1.2's newly invented 'focusin', 'focusout',
'activate' and 'zoom' and instead stick with DOMFocusIn, DOMFocusOut,
DOMActivate and SVGZoom (which provides backwards-compatible with both
DOM2 Events [for all but zoom] and SVG 1.1).

* We would deprecate SVGLoad, SVGResize and SVGScroll and replace with
'load', 'resize' and 'scroll' (which provides unified event names with
DOM2 Events and latest drafts of DOM3 Events). I don't believe that Tiny
1.2 user agents need to worry about backwards compatibility since Tiny
1.1 did not have scripting, but Full/Basic 1.2 user agents will need to
do the double-dispatching that Anne has suggested in order to be
backwards-compatible with Full/Basic 1.1.

Jon


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Maciej Stachowiak
Sent: Monday, April 03, 2006 1:22 AM
To: Anne van Kesteren
Cc: www-svg@w3.org
Subject: Re: [SVGMobile12] event aliasing



On Apr 2, 2006, at 12:52 PM, Anne van Kesteren wrote:

>
> On Sun, 02 Apr 2006 13:32:35 +0200, Doug Schepers  
> <doug.schepers@vectoreal.com> wrote:
>> [...]
>> Thoughts?
>
> I hope to reply to the rest of your e-mail at some later point.  
> Regarding event aliasing, how about dropping it and dispatching  
> both the "legacy" and new event instead? None of the events is  
> cancelable (except for the newly introduced activate which can be  
> dropped) so that shouldn't cause any problems. You require UAs to  
> support both events, authors to use the non-deprecated event and  
> you're done.

This sounds like a really good idea to me. Dispatching both is much  
easier to explain with reference to DOM Events and doesn't require  
UAs to implement whole new concepts like event alias tables and  
events that change their name during dispatch.

Regards,
Maciej

Received on Monday, 3 April 2006 14:26:02 UTC