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

On Wed, 02 Feb 2011 20:29:52 +0100, Dirk Schulze <vbs85@gmx.de> wrote:

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

Maybe, but it still depends on what was intended with "raster images" in  
this context.

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

Opera 11 behaves the same as Batik 1.7 on the testcase at the bottom of  
this mail.

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

So your preferrence would be to remove the pixel-checking section?

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

A more complete example would have different cursors on the different  
parts, one on the image element, and another on the circle element. Under  
no circumstances should the cursor on the circle be used, but the one on  
the image should be used (and depending on whether the image captures  
events on the transparent parts or not, the cursor on the rect element).

At the moment Opera doesn't consider the width/height of the image element  
as the geometry that can be hit in case an svg was referenced, but rather  
what was actually painted (excluding filters etc). I think there are valid  
use-cases for both the opaque-rectangle case and the one where the  
transparent parts means the click goes through. Note: this is not the same  
as checking the opacity value, it's more as if the referenced svg was  
actually included as a nested svg fragment.

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 Monday, 7 February 2011 09:42:30 UTC