Re: SVGT 1.2: "evt" vs "event" as the implicit event argument to event handlers

On Apr 20, 2006, at 8:35 AM, Doug Schepers wrote:

> Hi, Maciej-
>
> Thanks for your suggestion. We talked it over, did some research, and
> discussed the ramifications of your suggestion. Our reply is below.

Thanks for considering it. Comments below.

>
> Maciej Stachowiak wrote:
> |
> | SVG Tiny 1.2 calls for handler element bodies to implicitly create a
> | function with a paramater named "evt" for the event. SVG Full
> | 1.1 did
> | the same for event handler attributes. However, the longstanding
> | universal practice of (X)HTML UAs is to name this parameter "event".
> | It seems like it will be terribly confusing in a CDF enviornment for
> | SVG event handlers to name this parameter "evt" and for other
> | languages to use "event", especially since many major browsers are
> | now implementing HTML+SVG. There does not seem to be any
> | advantage to "evt".
> |
> | I recommend renaming this parameter from "evt" to "event".
> | This would
> | break compatibility with SVG 1.1 but the alternative is ongoing
> | confusion for content authors. Another option is to require both
> | "evt" and "event" parameters but deprecate "evt".
>
>
> SVG references DOM2 for the event listener functionality, including  
> the
> names of the parameters. DOM2 does not mention the parameter  
> 'event', but
> does explicitly define 'evt' (of type Event) [1]. DOM2, DOM3, SVG, and
> VoiceXML all use 'evt', and other specs implicitly use it by  
> referring to
> DOM2, so we feel like we that there is an established precedent  
> within W3C
> specs to use 'evt'.

The name of the parameter in IDL carries no precedential value, since  
it has no effect on user code. It could be called "blarglesnitz" and  
all listeners added via addEventListener would have the exact same  
behavior as today. Since the value of this name has no effect, it  
cannot be considered normative.

> Also, there is a lot of existing SVG content that uses
> 'evt', so it's not just a matter of breaking compatibility with the  
> SVG 1.1
> spec.

Are you talking about 1.1 content or 1.2 content? 1.1 did not include  
<handler>, so there can't be valid 1.1 content using it. 1.2 is not  
yet even a CR, so even if content authored against it exists,  
compatibility with such content does not seem like a valid argument.  
"We must be compatible with content authored against a working draft"  
is not a reasonable way to make a spec. You would have a valid point  
for event listener attributes however, when/if they are added back to  
1.2.

> We could not find the parameter 'event' defined in any XML or XHTML  
> spec,
> but we recognize that it is widely implemented in HTML UAs. We  
> suggest that
> a good way forward is to require both 'event' and 'evt', as you  
> suggest, but
> to deprecate 'event' instead. However, this is outside the scope of  
> the SVG
> WG, but may be appropriate for WebAPI, and should be addressed in  
> CDF, as
> well.

A) I agree that changing what "event" or "evt" means for XHTML or  
HTML event handler attributes is out of scope for SVG.

B) However, in the case of SVG, adding "event" as a second supported  
name for the implicit event parameter (or replacing "evt") would  
clearly be in scope for the SVG WG, and clearly out of scope for Web  
API and CDF. To make this change in a separate spec would require  
directly contradicting the SVG 1.2 Tiny spec as written. Therefore I  
strongly disagree if you think some other working group should change  
what SVG means.

C) I strongly disagree that "event" should be deprecated instead of  
"evt". There are many orders of magnitude more HTML documents than  
SVG documents, thus where the two disagree on a point of arbitrary  
naming it is much more sensible to change SVG. There is really no  
significant way in which "evt" is a better name than "event", so the  
change that results in less content changing is the better one, if we  
want this to eventually be harmonized.

> If this does not satisfy your suggestion, please let us know within  
> 2 weeks.

I interpret your response as saying that (1) no change will be made  
to the SVG spec; (2) the semantics of SVG ought to be changed by  
other working groups; and (3) HTML should be changed such that "evt"  
is supported in the body of event listener attributes and "event" is  
deprecated. I find (1) regrettable and (2) and (3) completely  
unacceptable for reasons stated above. Please let me know if I  
misinterpreted your reply.

Regards,
Maciej

Received on Friday, 21 April 2006 21:37:29 UTC