RE: [SVGMobile12] event aliasing

Hi Doug,
Thanks for trying to take this bull by the horns. I have added
supplemental comments inline preceded by "[JON]". 

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. What
would we lose and what we break? Here is my analysis of the seven events
which use event aliasing:

DOMFocusIn (backwards-compatible base event) / focusin (proposed alias
event) 
DOMFocusOut (backwards-compatible base event) / focusout (proposed alias
event)
DOMActivate (backwards-compatible base event) / activate (proposed alias
event)

   SVG Tiny 1.2 could certainly get by without the three proposed alias
events (focusin, focusout, activate). We can't get rid of the original
events (DOMFocusIn, DOMFocusOut, DOMActivate) because they are in both
Full/Basis 1.1 ultimately there will be a Full 1.2 which needs to be
upwardly compatible with both Tiny 1.2 and Full 1.1. Thus, nothing would
break here is we dropped these three event aliases (i.e., focusin,
focusout, activate).

load (proposed base event) / SVGLoad (backwards-compatible alias event)
resize (proposed base event) / SVGResize (backwards-compatible alias
event)
scroll (proposed base event) / SVGScroll (backwards-compatible alias
event)
zoom (proposed base event) / SVGZoom (backwards-compatible alias event)

   SVG Tiny 1.2 could certainly get by with no aliasing for these
events, also, and just stick with the existing event names from Full 1.1
(i.e., SVGLoad, SVGResize, SVGScroll, SVGZoom). We can't get rid of the
existing event names (SVGLoad, SVGResize, SVGScroll, SVGZoom) because
they are in both Full/Basis 1.1 for scripting and ultimately there will
be a Full 1.2 which needs to be upwardly compatible with both Tiny 1.2
and Full 1.1. 

   For SVGLoad, as Doug mentions below, it has different semantics that
HTML's load event. Thus, it is arguable that should use a different
event name anyway. Thus, Tiny 1.2 could continue to use "SVGLoad".

   For SVGResize and SVGScroll, there has to be some sort of mechanism
to address both backwards compatibility issues with Full/Basic 1.1 and
to deal with the fact the UAs that support both HTML and SVG will have a
single, unified notion "window resize" event. For SVGScroll, observe
that it is fired also when the graphic is panned, not just when a
scrollbar widget is manipulated.

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

In summary, my analysis is that event aliasing could be dropped from
Tiny 1.2, but only if everyone agrees that:

   * Event listeners for "SVGResize" which have an <svg:svg> element as
an event target will receive window resize events
   * Event listeners for "SVGScroll" which have an <svg:svg> element as
an event target will receive scrolling and panning events.

This seems like this simplist approach from a process perspective. What
we lose with this approach is the ability to clean up and unify event
names, but it looks like any attempt to clean up (e.g., deprecate the
unfortunate "DOM" and "SVG" prefixes on event names) and unify is going
to be a highly expensive standards task.

Jon


-----Original Message-----
From: public-cdf-request@w3.org [mailto:public-cdf-request@w3.org] On
Behalf Of Doug Schepers
Sent: Sunday, April 02, 2006 4:33 AM
To: www-svg@w3.org
Cc: public-webapi@w3.org; public-cdf@w3.org; www-smil@w3.org
Subject: 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...

[JON] My thinking is that the low-level DOM Event engine would include
an alias table, including entries such as "SVGLoad is an alias for load"
(although it would be represented in a data structure). It would be up
to the implementation whether to hard-code the table based on what
formats it supports (e.g., if it supports SVG, then it might hardcode
the SVGLoad alias) or whether it exposed an extensibility system such
that language format implementations can register their aliases.

[JON] In addition to maintaining this internal, unexposed table of event
aliases, the low-level DOM Event engine would have to implement aliasing
on two fronts: 
  (a) whenever the base event is to be dispatched, the event engine
needs to look for registered event listeners both for the the base event
(e.g., "load") or any event aliases (e.g., "SVGLoad") and dispatch the
given event to the handlers associated with event listeners for either
the base event or the event alias. When dispatched, the event name is
changed to match the event named used when addEventListener***() was
called.
  (b) if an alias event is create/initialized/dispatched via script
using createEvent() and further initialized via initEvent***() and then
dispatched via dispatchEvent(), the event engine must dispatch the alias
event to whatever event listeners which are registered on the base event
or any aliases for the base event.



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.

[JON] Peter's response is not inconsistent. The event alias has a
different event name than the base event. From the scripting
perspective, the base event (e.g., load) and the alias event (e.g.,
SVGLoad) are two entirely different events. However, under the hood, the
event engine would perform the redirection that I describe about such
that event listeners for the base event or alias event would be
dispatched a particular event no matter whether the particular event
originated as a base event or event alias.

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.

[JON] The easiest thing from an implementation perspective would be that
a UA which supports SVG (and thus according to the latest Tiny 1.2
draft, the UA would also have to support the event aliasing required by
SVG) would choose to support event aliasing universally, versus finding
a way to turn off event aliasing for non-SVG content Thus, I would
suggest that content developers should not use SVGScroll within HTML
content, but UAs would be allowed to support it.

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#SMILPro
file
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 18:45:24 UTC