Remove un-implemented pointer-events "painted" rules for images

[AmeliaBR]

The pointer-events definition contains detailed rules for "raster images" (presumably, any image embedded with <image>). A key feature is that an image should only be considered "painted" in areas where it doesn't have full transparency.

There are two problems with this:

• it provides access to per-pixel image data without any requirements for cross-origin security restrictions
• none of the browser engines (as far as I can tell) implements it this way

Based on my testing (CodePen demo) browsers treat an <image> element with transparent regions as interactive over its full rectangular dimensions, regardless of whether the image is same or cross-origin.

[BigBadaboom]

none of the browser engines (as far as I can tell) implements it this way

I suspect that this was mostly because the spec has a somewhat ambiguous reading:

For raster images, hit-testing is either performed on a whole-image basis (i.e., the rectangular area for the image is one of the determinants for whether the image receives the event) or on a per-pixel basis (i.e., the alpha values for pixels under the pointer help determine whether the image receives the event):

I think the original author was probably referring to the fact that some values ("visiblePainted" and "painted") require pixel level hit testing, and some don't. The former options include the the text:

if any pixel from the raster image which is under the pointer is not fully transparent

whereas the remaining options talk about:

the rectangular area of the image

A loose reading of the introductory paragraph could be interpreted to mean that implementations had a choice whether to use pixels or not. I hope the spec doesn't get changed to remove the per-pixel options. If it doesn't, then perhaps the intro should be modified to remove any ambiguity.

Browser bug reports for this issue here:

• https://bugzilla.mozilla.org/show_bug.cgi?id=311942
• https://bugs.chromium.org/p/chromium/issues/detail?id=806468

[BigBadaboom]

This issue has popped up on Stack Overflow a few times recently. People expect transparent pixels to be transparent to clicks.

Currently, the only way to get the expected behaviour is to use a <clipPath>. But if they are not using pre-defined images, clipPaths are not really feasible, unless they want to add code to generate them.

https://stackoverflow.com/questions/48447142/svg-how-to-ignore-pointer-events-on-transparent-parts-of-an-image

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

[dirkschulze]

Example for pointer events and mask:
https://codepen.io/krit/pen/vQKpjQ

Example for pointer events and clip-path:
https://codepen.io/krit/pen/OaXzQe

The clipping is taken into account for hit testing, masking is not. Same behaviour in Firefox, Chrome and WebKit.

[dirkschulze]

bounding-box does not take clipping into account, updated test above. The definition of pointer-events should reflect all that.

[fsoder]

bounding-box does not take clipping into account

It does. In your test (https://codepen.io/krit/pen/OaXzQe) you have pointer-events: bounding-box on the use, so you end up hitting the bounding box of the use. (Compare to when you have a/the clip-path on the use itself.)

[dirkschulze]

@fsoder Thanks! Updated the codepen.

[css-meeting-bot]

The SVG Working Group just discussed Remove un-implemented `pointer-events` "painted" rules for images, and agreed to the following:

• RESOLVED: Image pixel data isn't used for hit testing

The full IRC log of that discussion

<myles> TOPIC: Remove un-implemented `pointer-events` "painted" rules for images
<myles> GitHub: https://github.com//issues/322
<myles> krit: This is about the part of pointer events for raster images. I don't know why it's specific to raster images. ANyway, the spec says you look at the pixels inside the raster image and check the transparency. If the pixel is transparent, it isn't considered in the image for pointer events. Suggestion: Drop this requirement because it's not implemented anywhere
<myles> AmeliaBR: It's not implemented anywhere, that's the deciding factor. The reason it's not implemented is because of security concerns, not wanting script to be able to access the pixel data of an image that might be cross origin.
<myles> krit: it's a good excuse.
<myles> AmeliaBR: The main thing it comes down to: It's not implemented, it's not consistent with HTML, and I can't see anyone out there relying on it because there aren't really any other interactive implementations other than browsers
<myles> krit: Proposal: Just rely on the bounding box of the element. I made a pull request to just remove the spec text about transparent pixels
<myles> AmeliaBR: I haven't looked at the PR, but it sounds good
<myles> RESOLVED: Image pixel data isn't used for hit testing