[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] ISSUE: should no-target-object block event dispatch?
Hi, See inline... Wednesday, August 24, 2005, 4:36:00 AM, Dieter wrote: DW> Hi Lofton, DW> 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. DW> In 5.7.10, explanation of event types, the expression "if any" is used a DW> lot. That suggests that the event _is_ in fact dispatched if there is no DW> APS under the mouse. DW> Option 1: remove the "if any" in various locations, change the bullet point DW> above to "the event is discarded." DW> Option 2: change the above to support events outside of an APS. DW> My recollection is that we didn't want to handle events outside of an APS, DW> if this is right, we should go for option 1. I apologies, but I don't understand what you are trying to say. >> >* 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. DW> There can't be an event handler at the Picture level, because the DW> addEventListener funtion is on the metafile interface. DW> Suggestion: change to reflect this. Right, Picture needs to change to Metafile. >> >* Otherwise, if the target object has an appropriate event >> handler for >> >the given event, the event is dispatched to the target object. DW> There is no way to add an event listener to an individual object, DW> so this needs to be removed. I agree. >> >* 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. DW> Again, change Picture to Metafile. DW> However, this doesn't make sense, as Lofton pointed out. >> >* Otherwise, the event is discarded. DW> No. We still have internal link handling, i.e. linking by linkURI DW> attributes found in the file. Yes, but Lofton only extracted a small section of that chapter, we do cover this in: The processing order for user interface events is as follows: ... -- Benoit mailto:benoit@itedo.com DW> Regards, DW> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]