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

>> 
>> <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.

Hm, Okay. You could take it as invisible... indeed.

> 
> ...
>> 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.

I definitely don't want to remove this part :-) But if we would consequently use these pointer-events for filtered targets and take the example above, a rect of (0,0,100,100) should give a hit for pointer-events=painted. Should it there be a hit in (100,0,100,100) for 'fill'? And 'all' is (0,0,200,100)? I think this is mainly what Robert meant with:

Robert O'Callahan:
> If pointer-events:visiblePainted is used on an <image src="foo.svg"> to let the pointer "go through" transparent pixels of the image, and foo.svg uses filters internally to construct the image, I would say that those filters *should* affect the pointer, wouldn't you?



 Erik Dahlstrom:
> That depends on what "raster image" means to you, since that's what the pointer-events section you refer to has requirements on. I would say that <image xlink:href="foo.svg"> is not a raster image, whereas for example <image xlink:href="foo.png"> is. It would be simpler if the additional requirements were dropped, which would make both of these cases behave in a consistent manner.
Does it mean not to handle pointer events on SVG's embedded into a <image> tag? I tested the example on the bottom of this mail in Opera, WebKit, FF and Batik. And just Batik seems to give the correct hit. And speaking for WebKit, it would be as difficult to support hit detection just for non-transparent parts as it would be for raster images. At least at the moment.

> 
>> 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.
...
> 
> 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.
> ]]

In my last mail I just thought about what the user would expect but was not very precise about pointer-events itself. I was thinking about the value visiblePainted. To the change in the spec. Even if I thought we had a similar phrasing in the masking section on SVG 1.1, it is not quite consistent now (I know this is one point why you started this discussion). According to the description for masking:  "The effect is as if the child elements of the ‘mask’ are rendered into an offscreen image" that means it is also some kind of raster image. The same applies to filters. So we should either check every pixel for its opacity level on all three cases (mask,filter,image), or remove this section completely. I doubt that you will see a implementation with pixel checking in the near feature for WebKit. This would collapse the performance to much.

Cheers
Dirk


<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect width="100" height="100" fill="green" cursor="pointer"/> 
<image width="100" height="100" xlink:href="svg-circle.svg"/>
</svg>

<!-- svg-circle.svg -->
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100" height="100">
<circle cx="50" cy="50" r="25" fill="red"/>
</svg>