- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 07 Feb 2011 10:41:51 +0100
- To: "Dirk Schulze" <vbs85@gmx.de>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, "Doug Schepers" <schepers@w3.org>, "www-svg@w3.org" <www-svg@w3.org>
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