Re: [SVGMobile12] event aliasing

* Jon Ferraiolo wrote:
>Feel free to wade through the long email below to read my responses to
>Doug, but up here at the top I will propose a different approach. Let's
>first ask whether we CAN WE JUST DROP EVENT ALIASING from Tiny 1.2.

My understanding is that "event aliasing" is supposed a lightweight
method to make implementations roughly behave as if they "support"
both the 'load' and 'SVGLoad' family of event types but without the
overhead that would entail. I don't think the overhead is big enough
to warrant the additional complexity; so yes,

  * "event aliasing" should be dropped,
  * "support" for the 'load' event types should be required,
  * the 'SVGLoad' types should be deprecated
  * onload="" should map to evt.type == 'load' event objects

Whether support for 'SVGLoad' types should be required in Tiny is
not clear to me, support for them would only aid authors who pro-
duce new content that should work in SVG Tiny 1.2 and SVG 1.1
implementations, which isn't trivial considering the differences
between the features available, you'd likely have to either write
some wrapper library or use entirely separate code paths.

>   For SVGZoom, there is no need for reconciliation with existing events
>in the DOM Events spec. Tiny 1.2 could continue to use "SVGZoom".

SVGZoom is, unlike the other SVG* event types, highly SVG-specific
as it implements SVG-specific inter- faces with SVG-specific context
information. I think this should be 'SVGZoom' in SVG 1.2.

How SMIL event based timing interacts with DOM Level 3 Events in
SMIL 2.1 and SVG 1.2 is an entirely different matter and should be
discussed in a separate thread in my opinion. I've made proposals
for that earlier on www-svg.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 2 April 2006 19:39:44 UTC