W3C home > Mailing lists > Public > www-archive@w3.org > April 2006

RE: [SVGMobile12] event aliasing

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Sun, 2 Apr 2006 23:57:30 -0400
To: "'Anne van Kesteren'" <annevk@opera.com>
Cc: <www-archive@w3.org>
Message-Id: <20060403035731.348D460BC7@filch.dreamhost.com>

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.


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

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


www.vectoreal.com ...for scalable solutions.
Received on Monday, 3 April 2006 03:57:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:57 UTC