Re: Pointer-events processing (Was: Re: Announcement: Last Call WD of SVG 1.1 Second Edition)

On Wed, 02 Feb 2011 14:15:35 +0100, Dirk Schulze <vbs85@gmx.de> wrote:

>
> Am 02.02.2011 um 13:37 schrieb Erik Dahlstrom:
>
>> On Wed, 02 Feb 2011 12:49:29 +0100, Dirk Schulze <vbs85@gmx.de> wrote:
>>
>>>
>>> Am 02.02.2011 um 11:21 schrieb Erik Dahlstrom:
>>>
>>>> However, a thing to note is that filters aren't meant to affect  
>>>> pointer-events processing at all, for the purposes of hit detection  
>>>> it's as if there was no filter applied [2].
>>>
>>> One possibility would be to take the filter region for pointer events.  
>>> But some SVG's take the complete viewport of the root SVG element as  
>>> filter region, because this solves the problem of a web developer to  
>>> determine the correct clipping region for drop shadows. It would be  
>>> much more helpful (but still not perfect) to just use the affected  
>>> area for pointer events. The problem is, that the specification does  
>>> not define how to determine this region (just the filter or primitive  
>>> regions for clipping), so it can't be defined that this region should  
>>> be used.
>>
>> I'm not sure I follow what you mean here. Are you saying you'd want  
>> filters to have an effect on pointer-events processing?
> At least another definition would be better:
>
> <svg xmlns="http://www.w3.org/2000/svg"  
> xmlns:xlink="http://www.w3.org/1999/xlink">
> <defs>
> <filter filterUnits="userSpaceOnUse" id="filter" x="0" y="0" width="100"  
> height="100">
> <feFlood flood-color="red"/>
> </filter>
> </defs>
> <rect x="100" width="100" height="100" fill="green"/>
> <rect x="100" width="100" height="100" filter="url(#filter)"  
> style="cursor:pointer"/>
> </svg>
>
> The filtered object has the pointer-event. The user wants to press the  
> green button. In reality he will press the red button, because we still  
> take the bounding box of the filtered element for pointer-events. And in  
> my eyes this is a security issue, since the user expect another behavior  
> and this could be misused.

I don't really see how that's any different from say an invisible rect  
capturing the events.

...
> I have not read the discussion about CSS3 pointer events yet, not sure  
> if the discussion is somehow related to this topic here, sorry. But in  
> my eyes it is always problematic to handle a pointer event on invisible  
> areas of objects.

That would remove large parts of the pointer-event property values (as has  
been done for the pointer-event property's application to html). You can  
specify "pointer-events=all" though, and it doesn't care about what  
'visibilty' is.

> On the other hand I fear that we end up analyzing every image (e.g.  
> intermediate images for masks, or filters) if a certain point/pixel in  
> it is fully transparent or not. This could be a really big performance  
> problem.

Indeed, that's the main rationale behind the decision to not have filters  
affect pointer-event processing.

> The same occurs to your discussion about rasterized images. The question  
> if we could take opacity=0 is difficult as well. The difference between  
> 0, 0.001 and 0.01 are not very high and depend on the contrast to the  
> background as well. If we just take an opacity of 0 for determine if we  
> handle the event or not, we would run into the same problem.

Yes, that's more or less the reason behind the text you see in the  
SVG1.1F2 spec today:

[[
By contrast, a mask (like a filter) is not a binary transition, but a  
pixel operation, and different behavior for fully transparent and  
almost-but-not-fully-transparent may be confusingly arbitrary; as a  
consequence, for elements with a mask applied, pointer-events must still  
be captured even in areas where the mask goes to zero opacity, or a filter  
makes the element invisible. If an author wishes to achieve an effect  
where the transparent parts of a mask allow pointer-events to pass to an  
element below, a combination of masking and clipping may be used.
]]

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 2 February 2011 15:13:35 UTC