Re: [SVGMobile12] event aliasing

Hi Doug,

Relevant thoughts for the SVG WG are described in  
http://www.w3.org/mid/op.s7eb6hzg64w2qv@id-c0020.oslo.opera.com 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/>

Received on Sunday, 2 April 2006 20:35:00 UTC