The default bug view has changed. See this FAQ.

implement SVG 'pointer-events' property for all elements

NEW
Assigned to

Status

()

Core
Layout
P2
normal
10 years ago
5 years ago

People

(Reporter: dbaron, Assigned: jwatt)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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.
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

10 years ago
would this make http://kart.finn.no/ work?
(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.
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.
Assignee: nobody → dholbert
marking wanted1.9.1? to get this in the triage queue.  
Flags: wanted1.9.1?
Priority: -- → P2
1.9.1+
Flags: wanted1.9.1? → wanted1.9.1+
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

9 years ago
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.
(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.)
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.
(Reporter)

Comment 11

9 years ago
Presumably also svg|foreignObject { pointerEvents:visible } ?
yeah, or else we give the foreignobject's inner block a pseudo-style with that.
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

9 years ago
Is there a final proposal for pointer-events in HTML based on the discussion here?
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

8 years ago
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
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

8 years ago
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

8 years ago
FYI, this feature landed in WebKit r39634
https://bugs.webkit.org/show_bug.cgi?id=11395

Comment 20

8 years ago
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?
Unassigning myself, as I haven't been working on this for a while (and I think jwatt is interested in looking into this? :))
Assignee: dholbert → nobody
(Assignee)

Updated

8 years ago
Assignee: nobody → jwatt
(Assignee)

Updated

8 years ago
Blocks: 410820
(Assignee)

Updated

8 years ago
Depends on: 508179

Comment 22

7 years ago
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).
(Assignee)

Comment 23

7 years ago
Note that each property value other than 'auto' and 'none' is marked as "SVG only" in that MDC article.

Comment 24

7 years ago
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
(Assignee)

Comment 25

7 years ago
(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.
Blocks: 674062
You need to log in before you can comment on or make changes to this bug.