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

I might be wrong but...

Isn't 'event' a property of the global window object, and 'evt' a parameter 
to the event handler. Older html browsers didn't pass any arguments to the 
event handler, thus the need for an 'event' property on the window object to 
identify the current active event for event handlers to use. (Also) passing 
the event as an argument to the event handler is in my opinion a good idea.

-
Sigurd Lerstad


>
>
> 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 Monday, 24 April 2006 16:22:39 UTC