RE: [SVGMobile12] event aliasing

Hi, Anne-

Just a partial follow-up.

Anne van Kesteren wrote:
| 
| > Jon does clarify[1] (well, at least elaborate on ;) [...]
| 
| I read that, my point was mainly that it wasn't in the draft.

Yes, this needs to be addressed one way or another.


| > 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".
|
| Yeah, he seemed to have a different idea about it.

Well, Jon defended Peter's position, but the subtlety of his argument passed
through my sleep-deprivation-fogged brain without my getting a good look at
its face.


| > | 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.

/sigh

  
| > 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...

Yeah, Bjoern says it comes from HTML+Time, right? This is like spaghetti
code.


| > 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 :-)

I know what to think of that. ;)


| > 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.

Okay, I must have been looking at an old reference. Thanks for for the
correction! It means that they are more similar than I thought.


| > 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?

No, sorry, I was referring to SVG's hosting implementation of SMIL... the
animation and timing stuff. That is where it is used. 


| > 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.

Then it's agreed. We dump DOM* events and specify hot bubblin'
"focusin/focusout" for DOM3. I'm glad we had this talk. ;)


| > 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 :-)

Fair enough.


| > 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?

That's how I read the comment, "Not intrudicing SVG specific "events" would
be another." On second glance, however, I guess you were referring to
aliased events, not necessary SVG-specific events like zoom, right?


| > 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.

Yeah... but does that apply to comments from *all* the LC periods? There's
been, like, 12 of them... ;)


Regards-
Doug

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

Received on Monday, 3 April 2006 03:57:41 UTC