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

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. Opera seems to solve this by not firering an event at all (not analyzed the behavior further). But you can see the behavior on Firefox or WebKit nightlies.

> 
>> Note, the same occurs to SVG masks. The spec wants the implementer to ignore masks for pointer events as well.
>> 
>> This gets a bigger problem, if the target element gets completely clipped away by the mask.
> 
> So you'd want mask to behave the same as clip-path? For all levels of opacity or just for opacity=0?
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. 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. 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.
Normally we should make sure on all cases if something is visible or not before handling pointer-events.

Cheers
Dirk

Received on Wednesday, 2 February 2011 13:16:13 UTC