RE: [SVGMobile12] event aliasing

Bjoern,
I think it is a dangerous precedent for existing approved specifications to be changed gratuitously because a small collection of people are not aware of implementations that might or might not support a given feature within that specification. In the case of event triggers for SMIL animation, an SVG implementation has to establish an internal event listener before it can marshall an event to start/stop timed elements, so it does not matter whether the SMIL animation elements' syntax says 'foo' and the DOM Events spec says 'bar'. Thus, unification of the events names in this case is gratuitous and I argue against changing the behavior for SVG's animation elements because it is not backwards-compatible, whether or not our small collection of people are aware of implementations that support these features. There are dozens (hundreds?) of implementations of SVG, most of which are not known to the public. I am aware of multiple embedded device implementations that use SVG inside, but these implementations are not available to run as browser plugins in IE, Firefox, Safari or Opera, and I only am aware of these implementations because these companies found a need to contact Adobe at some point. Adobe itself uses SVG in about 10 different ways, where ASV is just one of them, and we need a specification that doesn't change every time a new set of people decide to fix things they don't like.

Jon


-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] 
Sent: Monday, April 03, 2006 12:41 PM
To: Jon Ferraiolo
Cc: www-svg@w3.org
Subject: Re: [SVGMobile12] event aliasing

* Jon Ferraiolo wrote:
>For example, in your email, you only talk about load/SVGLoad, but do not
>address DOMFocusIn, DOMFocusOut, DOMActivate, SVGResize or SVGScroll,
>and thus according to my arithmetic, you only address 1/7 of the problem
>set.

I think I made it clear that I mean all SVG* event types that have
a counterpart in DOM Level 3 Events, so that includes SVGResize,
SVGScroll, SVGUnload, SVGAbort, and so on.

>These various decisions about event names and SVG's syntax relative to
>these events went to recommendation in the years 2000 (for DOM2 Events)
>and 2001 (for SVG 1.0) and we just have to live with them.

Do you know of actual implementations that behave in the way the SVG
1.1 Recommendation describes and content that relies on it? SVG 1.1
is very confused on how things are supposed to work, it says, for
example, that the name of the event that occurs when timed elements
repeat is "none", "repeat", and "repeatEvent". It is not clear to me
which name to use when, and how this interacts with synthesized event
types. With my proposal all such things would be well-defined and easy
to understand, specify and implement.
-- 
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 Monday, 3 April 2006 20:06:46 UTC