--- In [email protected], "ddailey" <[EMAIL PROTECTED]> wrote:
> I started to reply yesterday with a JavaScript approach: find all the graphical elements and determe whether the (x,y) point was inside or outside each. but it was so cumbersome I backed out. An alternative I thought of was the following: > > Suppose we could prevent an object from blocking the percolation of the mouse event through to objects that are "behind" it. > That is, suppose we could allow the mouse event to intercept both the front most object and the objects behind it. I couldn't find any javascript event definition that would redefine event bubble/trickle in this way though (sort of across z-indexes rather than across DOM levels), so I considered an alternative: on mouseover have the front- most object recognize the mouse is over it and remember that, thence becoming invisible or hidden (perhaps with a ghost-like boundary); each subsequent element which is under the mouse behaves accordingly, until the last such element (which knows it is last since nothing underneath receives a mousemove event) a click is then intercepted and passed to a function which keeps track of all the now transparent objects on top. > > I don't think it'll really work though -- too many mouseover, mouseout, mouseclick events to handle and manage just properly. But it did seem like an approach which would take advantage of the fact that objects already know enough about their own geometry to know when the mouse is or isn't over them (without a lot of JavaScript geometry being built). > David > Hi David, Before I wrote my original post I considered both approaches you describe. With your response I started to develop solutions to both in parallel. I had some success with the approach of artificially bringing all elements at a point to the front by setting the pointer- events attribute of the front-most element to null (and tracking each element with a temporary id attribute so I could later remove this and the pointer-events attributes). However, I ran into some event conflicts and reverted to the brute force approach of identifying each element by its coordinates. In my specific case, what makes the peformance acceptable and not cumbersome is that my 'canvas' is spatially divided into nested chunks so I can quite quickly locate elements instead of iterating over hundreds of them. Thank you again for your input - it was very helpful. Let's hope the developers of SVG implementations add this to their feature lists. Simon ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
