RE: [cgmo-webcgm] ISSUE: should no-target-object block event dispatch?

[Dieter Weidenbrück <dieter@itedo.com>]

Hi Lofton,

see inline. 

> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com] 
> Sent: Wednesday, August 24, 2005 12:51 AM
> To: cgmo-webcgm@lists.oasis-open.org
> Subject: [cgmo-webcgm] ISSUE: should no-target-object block 
> event dispatch?
> 
> 
> 5.7.10
> ----------
> There are some things in the 2nd bullet list that I don't understand:
> 
> >* If there are no graphics objects whose interactive region is under 
> >the mouse (i.e., there is no target object), the event is 
> not dispatched.
In 5.7.10, explanation of event types, the expression "if any" is used a
lot. That suggests that the event _is_ in fact dispatched if there is no
APS under the mouse.
Option 1:  remove the "if any" in various locations, change the bullet point
	     above to "the event is discarded."
Option 2:  change the above to support events outside of an APS.
My recollection is that we didn't want to handle events outside of an APS,
if this is right, we should go for option 1.


> >* Otherwise, there is a target object. If there is an event 
> handler at 
> >the Picture level with event capturing for the given event, then the 
> >event is dispatched to the Picture.
There can't be an event handler at the Picture level, because the
addEventListener funtion is on the metafile interface.
Suggestion: change to reflect this.


> >* Otherwise, if the target object has an appropriate event 
> handler for 
> >the given event, the event is dispatched to the target object.
There is no way to add an event listener to an individual object,
so this needs to be removed.

> >* Otherwise, the Picture is checked to see if it has an appropriate 
> >event handler. The event is dispatched to the Picture if one 
> is found.
Again, change Picture to Metafile.
However, this doesn't make sense, as Lofton pointed out.

> >* Otherwise, the event is discarded.
No. We still have internal link handling, i.e. linking by linkURI
attributes found in the file.


Regards,
Dieter


> 
> (Long story short ... draw a flowchart of the above, with 
> four Y/N decision branches ... something is wrong.  In words, 
> the long story is...)
> 
> I don't understand how the 2nd sentence of 2nd bullet relates 
> to the 4th bullet.  If there is an appropriate event handler 
> at the Picture level, how would the event-dispatch algorithm 
> ever get past the 2nd bullet?  2nd bullet says that eligible 
> Picture gets the event before eligible target object 
> (eligible = has handler), while 4th says eligible picture gets it
> *after* eligible target object.  I would think that we mean 
> the 4th, right?  I.e., most specific wins?  I.e., closest to 
> leaf wins?
> 
> I'm unclear why the dispatch-to-Picture (if eligible) of the 
> 2nd bullet should be contingent upon there being a target 
> object.  It basically
> says:  if you click on a blank area of the picture, the event 
> is not dispatched (so Picture could not receive the event).  
> Is that what we intended?
> 
> (Btw, the first bullet is effectively the same as SVG1.1.  
> SVG is now debating whether to change it, even at the expense 
> of being non-backward compatible[!], so that the containing 
> SVG element [i.e., our "Picture"] gets a chance at the event 
> if there is no target object.)
> 
> Thoughts?
> 
> Regards,
> -Lofton.
> 
> 
>