Pointer-events Suggestion

[rmaw]

Hello, it's my understanding that this is the email address I should
write to with a suggestion for an enhancement to the pointer-events spec
in SVG. Please redirect if this is not the case.



I am working on a SVG application that uses translucent rectangles.
Clicking or hovering with the mouse pointer over a rectangle fires an
event related to the specific rectangle. In many circumstances one
rectangle is partially or completely overlapping another but because
they are translucent the rectangle in the back can still be seen through
the one in the front. In this situation it is quite intuitive for a user
to click on the overlapping region and expect the events associated with
both rectangles to be triggered. Indeed, this is the desired behaviour I
want to program for.

The current pointer-events spec allows me to turn off the event capture
on the upper rectangle by setting pointer-events="none" on this
rectangle. This way the bottom rectangle receives the events. If I don't
do this, then only the top rectangle gets the events. I desire BOTH
rectangles to get the events but there seems to be no simple way to
achieve this. I imagine setting the upper rectangle to something like:  

pointer-events="spy"

This would allow the top rectangle to catch events but then immediately
release them to propagate to a rectangle beneath - the upper rectangle
would be "spying" on events. I'm guessing this type of
translucent-overlapping situation wasn't considered when the
pointer-events spec was written. Adding a "spy" or "catch-and-release"
type of behaviour would be valuable. Thank you for considering it.

Ryan Maw, P.Eng.

[Alex Danilo]

Hi Ryan,

--Original Message--:

>Hello, it's my understanding that this is the email address I should
>write to with a suggestion for an enhancement to the pointer-events spec
>in SVG. Please redirect if this is not the case.
>
>
>
>I am working on a SVG application that uses translucent rectangles.
>Clicking or hovering with the mouse pointer over a rectangle fires an
>event related to the specific rectangle. In many circumstances one
>rectangle is partially or completely overlapping another but because
>they are translucent the rectangle in the back can still be seen through
>the one in the front. In this situation it is quite intuitive for a user
>to click on the overlapping region and expect the events associated with
>both rectangles to be triggered. Indeed, this is the desired behaviour I
>want to program for.
>
>The current pointer-events spec allows me to turn off the event capture
>on the upper rectangle by setting pointer-events="none" on this
>rectangle. This way the bottom rectangle receives the events. If I don't
>do this, then only the top rectangle gets the events. I desire BOTH
>rectangles to get the events but there seems to be no simple way to
>achieve this. I imagine setting the upper rectangle to something like:  
>
>pointer-events="spy"
>
>This would allow the top rectangle to catch events but then immediately
>release them to propagate to a rectangle beneath - the upper rectangle
>would be "spying" on events. I'm guessing this type of
>translucent-overlapping situation wasn't considered when the
>pointer-events spec was written. Adding a "spy" or "catch-and-release"
>type of behaviour would be valuable. Thank you for considering it.
>
>Ryan Maw, P.Eng.

You should be able to attach an event handler on both rectangles and
both will receive the event.

That is standard DOM event bubbling behaviour.

If you're not getting events on both rectangles, then it's
likely the user agent you're using is buggy.

Cheers,
Alex

[rmaw]

Some parts of this message have been removed. Learn more about Nabble's security policy.

>You should be able to attach an event handler on both rectangles and

>both will receive the event.

>That is standard DOM event bubbling behaviour.

>If you're not getting events on both rectangles, then it's

>likely the user agent you're using is buggy.

>Cheers,

>Alex

 

Thanks for the tip, Alex. This would certainly work in some cases but, unless I’m missing something, I believe it’s only when one rectangle is a DOM child/descendant of the other, right? My rectangles are DOM siblings, and sometimes not even siblings but nieces and nephews. As I understand it, the bubbling event only moves along the DOM via parent/child relationships on it’s way to it’s target. My other rectangle isn’t in the path of event travel so it never would never receive the event.

 

Ryan

[Alex Danilo]

Hi Ryan,

--Original Message--:

>>You should be able to attach an event handler on both rectangles and
>
>>both will receive the event.
>
> 
>
>>That is standard DOM event bubbling behaviour.
>
> 
>
>>If you're not getting events on both rectangles, then it's
>
>>likely the user agent you're using is buggy.
>
> 
>
>>Cheers,
>
>>Alex
>
> 
>Thanks for the tip, Alex. This would certainly work in some cases but, unless I’m missing something, I believe it’s only when one rectangle is a DOM child/descendant of the other, right? My rectangles are DOM siblings, and sometimes not even siblings but nieces and nephews. As I understand it, the bubbling event only moves along the DOM via parent/child relationships on it’s way to it’s target. My other rectangle isn’t in the path of event travel so it never would never receive the event.

Yes, good point. Capture/bubbling does require the ancestry relationships to work.

That's certainly an interesting use-case you have. Maybe other  people will have
some useful suggestions.

Cheers,
Alex

>Ryan
>
>
>
>

[Jeff Schiller]

My only solution is a hack :(

Basically an invisible rect over the whole UI that receives all mouse
events.  Then use SVGSVGElement.getIntersectionList() on a tiny rect
centered on the mouse event.  This is a horrible hack, I know.

Unfortunately (fortunately?) getIntersectionList()/getEnclosureList()
are not implemented cross-browser, specifically Firefox.

Jeff

2009/11/5 Alex Danilo <alex@...>:

>
> Hi Ryan,
>
> --Original Message--:
>>>You should be able to attach an event handler on both rectangles and
>>
>>>both will receive the event.
>>
>>
>>
>>>That is standard DOM event bubbling behaviour.
>>
>>
>>
>>>If you're not getting events on both rectangles, then it's
>>
>>>likely the user agent you're using is buggy.
>>
>>
>>
>>>Cheers,
>>
>>>Alex
>>
>>
>>Thanks for the tip, Alex. This would certainly work in some cases but, unless I’m missing something, I believe it’s only when one rectangle is a DOM child/descendant of the other, right? My rectangles are DOM siblings, and sometimes not even siblings but nieces and nephews. As I understand it, the bubbling event only moves along the DOM via parent/child relationships on it’s way to it’s target. My other rectangle isn’t in the path of event travel so it never would never receive the event.
>
> Yes, good point. Capture/bubbling does require the ancestry relationships to work.
>
> That's certainly an interesting use-case you have. Maybe other  people will have
> some useful suggestions.
>
> Cheers,
> Alex
>
>>Ryan
>>
>>
>>
>>
>
>
>

[Dr. Olaf Hoffmann]

Hello,

just a suggestion for a workaround:
 
If the positions and sizes of the rectangles are known,
one can of course simply put a third rectangle with
fill-opacity 0 on top of the overlapping area to capture
the event and to start both actions - for example both
begins of a declarative animation or whatever has to
be started.
In case of a link-functionality one still has to think how
to open two targets at once - and whether this is really
intended by the user or not, of course ;o)

If one has n>2 rectangles partly intersecting of course
one has to do some more calculations to get all
those additionally invisible rectangles in the right order.
However, if the rectangles do not change at all or only
in a predictable way, this should work.


Olaf

[Andreas Neumann-7]

Hi,

I have no solution other than what Jeff suggested with
SVGSVGElement.getIntersectionList()

But I do also have use-cases besides Ryans use case for an enhanced
pointer-events handling that allows pointer-events to travel through to
all overlapping graphics elements below the mouse-cursor position.

In GIS it is very common having to penetrate through all map layers
(potentially many of them overlapping). As Ryan said, these are not
parent/child/grandchild, etc. relationships but purely spatial or
geometric relationships.

So having an improved pointer-events attribute like "spy"
"catch-and-release" or "penetrate" or whatever it is called, would be very
beneficial for GIS and other applications. This is something I would be
very glad if the SVG WG could pick it up for a later addition to the SVG
spec.

Andreas


On Thu, November 5, 2009 9:27 pm, Ryan Maw wrote:

> Hello, it's my understanding that this is the email address I should
> write to with a suggestion for an enhancement to the pointer-events spec
> in SVG. Please redirect if this is not the case.
>
>
>
> I am working on a SVG application that uses translucent rectangles.
> Clicking or hovering with the mouse pointer over a rectangle fires an
> event related to the specific rectangle. In many circumstances one
> rectangle is partially or completely overlapping another but because
> they are translucent the rectangle in the back can still be seen through
> the one in the front. In this situation it is quite intuitive for a user
> to click on the overlapping region and expect the events associated with
> both rectangles to be triggered. Indeed, this is the desired behaviour I
> want to program for.
>
> The current pointer-events spec allows me to turn off the event capture
> on the upper rectangle by setting pointer-events="none" on this
> rectangle. This way the bottom rectangle receives the events. If I don't
> do this, then only the top rectangle gets the events. I desire BOTH
> rectangles to get the events but there seems to be no simple way to
> achieve this. I imagine setting the upper rectangle to something like:
>
> pointer-events="spy"
>
> This would allow the top rectangle to catch events but then immediately
> release them to propagate to a rectangle beneath - the upper rectangle
> would be "spying" on events. I'm guessing this type of
> translucent-overlapping situation wasn't considered when the
> pointer-events spec was written. Adding a "spy" or "catch-and-release"
> type of behaviour would be valuable. Thank you for considering it.
>
> Ryan Maw, P.Eng.
>
>
>

--
Andreas Neumann
http://www.carto.net/neumann/
http://www.svgopen.org/