Hi Doug,
Relevant thoughts for the SVG WG are described in
http://www.w3.org/mid/[EMAIL PROTECTED] as a
somewhat shorter reply to this e-mail. Below are some thoughts on the
points you made. (Not all of them though.)
Jon does clarify[1] (well, at least elaborate on ;) [...]
I read that, my point was mainly that it wasn't in the draft.
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...
Heh, exactly :-)
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.
Yeah, he seemed to have a different idea about it.
| 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?).
Right, SMIL has its own set of (incompatible) focus events.
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].
Hmm fun! That makes them consistent with HTML...
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... ;)
SMIL also has 111 namespaces. I'm not sure what to think of it actually :-)
| 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.
The problem I saw is that you have this situation:
A is an alias for B
C is an alias for D
Both C and D can be used as valid names inside SMIL animation. B can too.
A can't.
(A is DOMActivate, B would be activate and C and D are load and SVGLoad.)
But "load" in SVG can be placed on multiple elements, while in HTML, it
only
applies to the document as a whole.
That's not true actually, it's also dispatched on <img>, <iframe>,
<object>, <embed>, <body>, <frame>, <frameset>, <link>, <script> and
perhaps some others I missed. Quite useful too.
(I omitted the next part which talked about expectations on the amount of
firing of the load event in HTML versus SVG. Besides that this contradicts
the above it's actually not really a problem unless you'd have a capture
listener which SVG Tiny 1.2 doesn't support at the moment I believe.)
| 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.)".
But SMIL doesn't have focusin, focusout and activate, does it?
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.
Dunno, I dislike the DOM* prefix a lot.
Regardless, I think that arguing over which is more "user friendly" is
probably a fruitless exercise.
Which is exactly why I'd like it out of the specification :-)
However, SVG does have need to introduce its own events (zoom, for
example), so I don't agree with you there.
Did I ever said SVG should not be allowed to do that?
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,
http://www.w3.org/2005/10/Process-20051014/tr.html#doc-reviews
Starting with a Last Call review up to the transition to
Proposed Recommendation, a Working Group MUST formally
address any substantive review comment about a technical
report and SHOULD do so in a timely manner.
Cheers,
Anne
[...]
[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-interfaces-h3
[5]
http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil21-profile.html#SMILProfileNS-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
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
