Open Bug 380573 Opened 17 years ago Updated 2 years ago

implement SVG 'pointer-events' property for all elements

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

People

(Reporter: dbaron, Assigned: jwatt)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(2 files)

simple testcase
1.71 KB, text/html
Details
WIP patch v1
16.54 KB, patch
Details | Diff | Splinter Review 
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.
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.
Attached file 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+
Attached patch WIP patch v1 — — Splinter Review 
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 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.
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).
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.
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)
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".
FYI, this feature landed in WebKit r39634
https://bugs.webkit.org/show_bug.cgi?id=11395
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: nobody → jwatt
Blocks: 410820
Depends on: 508179
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).
Note that each property value other than 'auto' and 'none' is marked as "SVG only" in that MDC article.
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
(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.
11 Years have passed... What is with the integration?

I see it's possible, but it still seems to be buggy. Especially in the case of a child-element, that tries to re-enable its pointer-events... Anybody else noticed this?
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: