RE: [SVGMobile12] event aliasing

Hi, Anne-

This email is not an official reply, I'm just trying to work out the issue
for my own (and possibly others') understanding. I think I answer a few
questions, but I raise just as many. I'm cross-posting this to WebAPI, CDF,
and SMIL (please don't kill me!), since I think this discussion is relevant
to all of these groups.

Anne van Kesteren wrote:
| 
| http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/interact.htm
| l#SVGEvents  
| seems, besides providing a list of events, to introduce a concept of  
| aliasing events, but it doesn't clearly define how this 
| works. I believe  
| the clarification said to be made in  
| http://www.w3.org/mid/6.1.1.1.2.20050118043807.01f18178@mailsj
| -v1.corp.adobe.com  
| isn't really done. The questions raised in  
| http://www.w3.org/mid/41EDB04C.5090606@mit.edu can't seem to 
| be answered  
| given the current text. Yet these were comments on the first 
| Last Call document of SVGMobile12...

Jon does clarify (well, at least elaborate on ;) event aliasing a bit here
[1]: "This event aliasing for SVG affects all mechanisms that register event
listeners via namespaced events, which according to my accounting would be
XML Events (used within the context of SVG Tiny 1.2), svg:handler,
addEventListener, and addEventListenerNS. The aliasing does not apply to
SVG's use of SMIL; instead, the event strings used within the 'begin' and
'end' attributes are listed in the 'Animation event name' column within the
table in http://www.w3.org/TR/SVGMobile12/interact.html#SVGEvents."

His rationale is, "This is an inevitability given than there needs to be
some cleanup around the events defined within SVG 1.0 in order to make it so
that SVG will have a unified set of event names with DOM3 Events (which
happened after SVG 1.0) in order to allow proper event bubbling across SVG
and HTML (and other languages). Event bubbling won't work in a compound
document scenario if there is not agreement about the QNames of the shared
events."


To me, this seems like a pretty unambiguous idea. An event alias is just
another string for the same logical event... Right? Right? Uh, wait...

In reply to Boris' email [2], Peter Sorotokin (also from Adobe) says [3]
that  
   target.addEventListener("type1", listener, false);
   target.addEventListener("type2", listener, false);
are two different event listeners, firing two different events, and that
removing "type2" would still leave "type1". His rationale? "I think we'd get
in trouble with the DOM otherwise."

That is totally *not* what I would have expected, either from intuition nor
from Jon's comment.

DOM2 [4] clearly states of 'addEventListener', "If multiple identical
EventListeners are registered on the same EventTarget with the same
parameters the duplicate instances are discarded. They do not cause the
EventListener to be called twice and since they are discarded they do not
need to be removed with the removeEventListener method." Similarly,
'removeEventListener' makes only the following exception, "If a listener was
registered twice, one with capture and one without, each must be removed
separately." Since the aliased event types are the "same event", the
listener should be removed. 

It's likely that there are just some crossed wires here, rather than an
internal contradiction in the concept of event-aliasing. What Peter may have
meant by "get in trouble with the DOM" is that SVG should not dictate what
another Spec does (which is obviously correct) and should not change
behavior defined in another Spec but reused in SVG (which seems to be where
some trouble is arising).

To me, it is clear that to have events with different literals (in the
lexical space) but representing the same event (in the value space) handled
smoothly in a compound document, they should represent the identical event;
thus, an "activate" event in an SVG fragment might be handled by the
appropriate "DOMActivate"-registered handler in an outer HTML document, and
have the same behavior (as regards bubblin', cancellin', and such-like).

But this is problematic... does that mean that an "activate" event listener
registered on an HTML element should behave the same way? How about
"resize/SVGResize", "scroll/SVGScroll", and "zoom/SVGZoom"... can all these
be registered on HTML elements? I think that Boris, Cameron, Bjoern, and
others have rightly pointed out the problems here.

So, what I took to be pretty clear is, as you say, definitely open to
radical interpretation. Jon is smart, Peter is smart, I'm... well, ok, let's
just say that people of varying aptitudes can look at the same thing and see
differences.


| It's also not clear from the text why DOMFocusIn is not an alias for  
| focusin in SMIL timing attributes (is that term defined somewhere?), 

I don't believe that focusin is defined in SMIL, but in SVG (is that
right?). Both SMIL and SVG reference DOM2 "DOMFocusIn" as the source for
their focus event, which SVG calls focusin and SMIL calls "focusInEvent".
Mysteriously and unfortunately, SMIL says that "The focusInEvent [...] does
not bubble." This differs from DOMFocusIn, obviously, and it's not clear why
they specify that; perhaps the SYMM WG can clarify their rationale, and
might even be willing to change this behavior in an errata, to come in line
with other Specs. They do need an errata anyway, since they define a
"focusInEvent" literal in their definitions, but use "focus" in their
examples [6].

Interestingly, the SMIL Spec (a Rec, mind you) seems to implicitly use event
aliasing without calling it such; for what it's worth, at least the SVG Spec
introduces the concept, even if it doesn't sufficiently define it... ;)   

But a seeming contradiction lies in Jon's assertion that "aliasing does not
apply to SVG's use of SMIL", since both SVG and SMIL reference the DOM2
"DOMFocusIn" event... so it would be expeditious (and less confusing to
authors and implementors) if both "focusin" and "DOMFocusIn" were allowed as
event literals in SMIL events; for that matter, it would ideally allow
"focusInEvent" as well. This seems to argue for the presence of some
event-aliasing mechanism.

Bjoern points out this inconsistency in valid event literals [7]. Allowing
the full range of event types and literals might also facilitate the use of
events in a non-imperative (read: JavaScript) language, such as a potential
declarative language or a model like XForms.

Note that while I talk about "DOMFocusIn" above, the same applies to
"DOMFocusOut", "DOMActivate", and possibly other events.


| but load is for SVGLoad...

Again, I too see a problem here. The "load" event in SVG may have different
behavior than its HTML/DOM2 equivalent. Neither bubble, so that's fine.  But
"load" in SVG can be placed on multiple elements, while in HTML, it only
applies to the document as a whole. In both, the target element must have
all its children and external resources resolved (in HTML, the whole
document, in SVG, e.g. a group that contains multiple raster images), so
again, that's fine. But that means that in HTML, the event is expected to
fire only once, while in SVG, it may fire many times. This is likely to
cause havoc to innocent byscripters who just want to know when *all* the
resources are loaded, not just some of the pictures in and SVG fragment. Of
course, if the author is the one registering event listeners, they should
keep track of what they are doing, but there may be complex situations where
it may be difficult to disentangle the functionality of both "load" events.

This seems to be a problem with aliasing events in a compound document where
there is no namespacing or scoping of the event literals. 


| It also confuses me that the specification talks about "user 
| friendly". I think for example that there could be arguments for 
| DOMFocusIn to be more "user friendly" than focusin. Consistency
| would be one. Not intrudicing SVG specific "events" 
| would be another.

Jon seems to agree with this idea [8], saying "SVG should not add this 
event alias and instead should use 'DOMFocusIn' as the only DOM event name 
while sticking with 'focusin' for SMIL for backward compatibility reasons. 
(Same for [DOM]focusout and [DOM]activate.)".

Personally, I prefer the shorter, uncamelled "focusin/focusout", but that
may be a non-starter. I would happily go with that if everyone was cool with
it, but I think I'm dreaming. Regardless, I think that arguing over which is
more "user friendly" is probably a fruitless exercise.

However, SVG does have need to introduce its own events (zoom, for example),
so I don't agree with you there.


| In any case, it would be good if the next version of the 
| specification clearly addresses all the flaws pointed out  
| and that adequate responses to the commenters have been made.

I agree with the larger point that it should be defined better and perhaps
have some things better thought out in the CDF context (if that's not better
placed in the scope of the CDF WG). 

Due to the large number of comments over a protracted period, over which the
SVG Spec has changed to meet reviewer requirements several times, it may be
difficult to respond to all the comments individually, especially as some of
them may have become irrelevant in light of subsequent changes, but I hope
we will be able to capture them all and address them with the attention
deserved. I think even more important, though, is that we come up with a
consistent and usable mechanism where all the needs of authors and
implementors are met, while maintaining backwards compatibility with earlier
versions of the SVG Spec, current compatibility with all other W3C Specs,
and forwards compatibility with the goals of the future Web.  

Thoughts?


[1] http://lists.w3.org/Archives/Public/www-svg/2006Feb/0084.html
[2] http://lists.w3.org/Archives/Public/www-svg/2005Jan/0084
[3] http://lists.w3.org/Archives/Public/www-svg/2005Jan/0085.html
[4]
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Registration-inte
rfaces-h3
[5]
http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil21-profile.html#SMILProfile
NS-supported-events
[6] http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html
[7] http://lists.w3.org/Archives/Public/www-svg/2005Mar/0008
[8] http://lists.w3.org/Archives/Public/www-svg/2005Sep/0014.html


Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Sunday, 2 April 2006 11:32:57 UTC