Last Comment Bug 380573 - implement SVG 'pointer-events' property for all elements
: implement SVG 'pointer-events' property for all elements
Status: NEW
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P2 normal with 7 votes (vote)
: ---
Assigned To: Jonathan Watt [:jwatt] (back in October - email directly if necessary)
:
Mentors:
http://www.w3.org/TR/SVG11/interact.h...
Depends on: 508179
Blocks: 674062 410820
  Show dependency treegraph
 
Reported: 2007-05-13 10:28 PDT by David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
Modified: 2012-08-05 17:56 PDT (History)
28 users (show)
dsicore: wanted1.9.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
simple testcase (1.71 KB, text/html)
2008-05-21 15:43 PDT, Daniel Holbert [:dholbert]
no flags Details
WIP patch v1 (16.54 KB, patch)
2008-06-16 17:45 PDT, Daniel Holbert [:dholbert]
no flags Details | Diff | Splinter Review

Description David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-05-13 10:28:35 PDT
I think that (instead of bug 380094) we should implement the SVG pointer-events property for all elements.  The definition of the property for SVG is at http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty .  This requires that:

 * we add a new value '-moz-auto', that is the default, and acts like 'visiblePainted' for SVG content and 'visible' for non-SVG content (for compatibility)

 * we treat the stroke-related values, for non-SVG, as referring to the border

 * we treat the fill-related values, for non-SVG, as referring to the background area, as defined by -moz-background-clip

Implementing the bits for text and raster images might be a bit more than we need, though.
Comment 1 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-05-13 19:29:08 PDT
Sounds good to me.

Implementing the raster image part would be great --- I've heard people (e.g. Google Maps) begging for the ability to pass events through translucent pixels.
Comment 2 R.K.Aa. 2007-06-16 23:32:52 PDT
would this make http://kart.finn.no/ work?
Comment 3 Daniel Holbert [:dholbert] 2008-05-20 15:27:39 PDT
(In reply to comment #1)
> Implementing the raster image part would be great --- I've heard people (e.g.
> Google Maps) begging for the ability to pass events through translucent pixels.

See also Bug 311942, on implementing this for raster images that are embedded in SVG.
Comment 4 Daniel Holbert [:dholbert] 2008-05-21 15:43:46 PDT
Created attachment 322014 [details]
simple testcase

This testcase just tries out all the various values of pointer-events, (plus -moz-auto, gibberish, and unspecified) and then prints the computed style that results.
Comment 5 Damon Sicore (:damons) 2008-06-04 16:48:59 PDT
marking wanted1.9.1? to get this in the triage queue.  
Comment 6 Damon Sicore (:damons) 2008-06-10 15:12:25 PDT
1.9.1+
Comment 7 Daniel Holbert [:dholbert] 2008-06-16 17:45:44 PDT
Created attachment 325355 [details] [diff] [review]
WIP patch v1

This simple patch just provides the infrastructure, but doesn't really change anything functionally yet.

Right now, the patch...
 - ...adds the -moz-auto value for pointer-events (which behaves like visiblePainted for SVG content)
 - ...adds "const nsPoint& aPt" parameter to GetMouseThrough (with the intention of extending this function to check for pixel transparency etc., based on the click position)  So far, this parameter is just ignored.

BTW, I'm currently managing the patch via a MQ mercurial patch-queue at:
 http://hg.mozilla.org/users/dholbert_mozilla.com/pointer-events-patches/
Comment 8 Robert Longson 2008-06-17 01:25:13 PDT
Comment on attachment 325355 [details] [diff] [review]
WIP patch v1

>diff --git a/layout/style/nsStyleStruct.cpp b/layout/style/nsStyleStruct.cpp
>--- a/layout/style/nsStyleStruct.cpp
>+++ b/layout/style/nsStyleStruct.cpp
>@@ -674,17 +674,17 @@ nsStyleSVG::nsStyleSVG()
>     mStrokeMiterlimit        = 4.0f;
>     mStrokeOpacity           = 1.0f;
> 
>     mStrokeDasharrayLength   = 0;
>     mClipRule                = NS_STYLE_FILL_RULE_NONZERO;
>     mColorInterpolation      = NS_STYLE_COLOR_INTERPOLATION_SRGB;
>     mColorInterpolationFilters = NS_STYLE_COLOR_INTERPOLATION_LINEARRGB;
>     mFillRule                = NS_STYLE_FILL_RULE_NONZERO;
>-    mPointerEvents           = NS_STYLE_POINTER_EVENTS_VISIBLEPAINTED;
>+    mPointerEvents           = NS_STYLE_POINTER_EVENTS_MOZ_AUTO;

What happens if you do getComputedStyle on an SVG element in an SVG document that does not have this style set or inherited. Will it still return an initial value of visiblePainted as it should per the SVG specification? 

Also what happens if you have an xhtml document with an svg element in the body? What should getComputedStyle return for the svg element? Since pointer-events inherit, it will get the style of its body parent (-moz-auto) unless you do something about that.
Comment 9 Daniel Holbert [:dholbert] 2008-06-18 11:36:51 PDT
(In reply to comment #8)

> What happens if you do getComputedStyle on an SVG element in an SVG document

> that does not have this style set or inherited. Will it still return an initial

> value of visiblePainted as it should per the SVG specification? 



That's a good question.  With the current patch, it'll return -moz-auto. (which behaves like visiblePainted for SVG, but has a different name)  That may not be correct behavior -- roc, dbaron, any thoughts?


> Also what happens if you have an xhtml document with an svg element in the

> body? What should getComputedStyle return for the svg element? Since

> pointer-events inherit, it will get the style of its body parent (-moz-auto)

> unless you do something about that.



Yes, and that's what's intended.  That way, in your example, the XHTML elements will behave like 'visible' and the SVG will behave like 'visiblePainted', which is what we're looking for AFAIK, per comment 0.
  (If we didn't use a special -moz-auto value, then the XHTML default 'visible' value would inherit to the SVG elements, and we don't want that to happen.)
Comment 10 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-06-18 12:16:12 PDT
It might be better to just disobey the spec slightly, make the initial value 'visible' but have a rule "svg { pointerEvents:visiblePainted; }" in the UA style sheet and lobby for a spec change to make that compliant. I'm not sure which is the lesser of evils.
Comment 11 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-06-18 12:51:54 PDT
Presumably also svg|foreignObject { pointerEvents:visible } ?
Comment 12 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-06-18 14:12:54 PDT
yeah, or else we give the foreignobject's inner block a pseudo-style with that.
Comment 13 Daniel Holbert [:dholbert] 2008-06-18 14:29:42 PDT
dbaron points out in IRC that we could probably also keep the -moz-auto value, and then change the behavior in nsComputedDOMStyle to translate '-moz-auto' into the appropriate value ('visible' or 'visiblePainted', depending on the element).
Comment 14 Simon Fraser 2008-07-29 13:56:17 PDT
Is there a final proposal for pointer-events in HTML based on the discussion here?
Comment 15 Daniel Holbert [:dholbert] 2008-09-23 10:57:25 PDT
Sorry I haven't updated this bug in a little while -- this feature isn't going to make 1.9.1, so it's on the back-burner for now.

I'll outline a proposal at some point soon, in the timeframe for 1.9.2 / 1.9.next.
Comment 16 Dean Jackson 2008-11-25 13:33:09 PST
FYI, I've documented something that we're looking at implementing. It's very rough, so comments welcome (this bug is a good enough spot for discussion)

http://webkit.org/specs/PointerEventsProperty.html
Comment 17 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-11-25 13:46:53 PST
A lot of people have asked for the ability to use an image's alpha channel as the hit-test mask. It would be nice to support that somehow. (But see http://markmail.org/message/w3fz4qxycfa2tbic)
Comment 18 Dean Jackson 2008-11-25 14:09:51 PST
Yeah. That's something we'd like to support eventually, but we wanted to make a simple first pass. The most common use case is just "make this element always ignore the pointer".
Comment 19 Dean Jackson 2009-01-07 16:04:24 PST
FYI, this feature landed in WebKit r39634
https://bugs.webkit.org/show_bug.cgi?id=11395
Comment 20 Dean Jackson 2009-01-07 16:06:05 PST
An open question is what the computed style value should be.  WebKit's current implementation now returns "auto" by default (even for SVG elements). Is this confusing?
Comment 21 Daniel Holbert [:dholbert] 2009-05-01 15:46:26 PDT
Unassigning myself, as I haven't been working on this for a while (and I think jwatt is interested in looking into this? :))
Comment 22 Tantek Çelik 2010-09-17 12:48:54 PDT
Looks like we now implement this and it's documented on DevMo:

https://developer.mozilla.org/en/css/pointer-events

I'm writing up 'pointer-events' for inclusion in the next CSS3-UI draft (which will be a return to Last Call Working Draft due to changes beyond the scope of post-CR).
Comment 23 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2010-09-17 13:35:27 PDT
Note that each property value other than 'auto' and 'none' is marked as "SVG only" in that MDC article.
Comment 24 Tantek Çelik 2010-09-17 13:56:24 PDT
Sorta - "The other values only apply to SVG **and behave like auto in other XML and HTML content**." - this is an important detail, and there are several ways of specifying things so that this is the effect that we get.

Currently working on converging the way that the separate Moz, Webkit, and Opera specs all describe essentially the same functionality. If you're curious about the details:

* https://developer.mozilla.org/en/css/pointer-events
* http://webkit.org/specs/PointerEventsProperty.html
* http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html and contextual commentary from the author:
 - http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
Comment 25 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2010-09-17 14:06:26 PDT
(In reply to comment #24)
> Sorta - "The other values only apply to SVG **and behave like auto in other XML
> and HTML content**." - this is an important detail, and there are several ways
> of specifying things so that this is the effect that we get.

The only reason that's the case is because I only implemented the 'none' value for non-SVG elements, not because I thought the other values should behave like 'auto'. In fact I do /not/ think the other values should behave like 'auto'. I'm still working out for myself what makes most sense for authors though.

Note You need to log in before you can comment on or make changes to this bug.