Repository navigation
Clarify relation of isPointInFill and pointer-events #416
Description
Currently the section Interface SVGGeometryElement is not very specific how isPointInFill and isPointInStroke correlate to the pointer-events CSS property.
The spec says:
Normal hot testing rules apply; the value of the
pointer-eventsproperty on the element determines wheather a point is considered to be within the full or stroke.
What happens when the property is set to stroke and we ask for isPointInFill? Or visibleStroke with visibility hidden and asking if the point is in the full area?
I suppose we follow the rules for hit testing as if the stroke value was set for pointer-events on isPointInSroke and take things like clipping path into account but not visibility? For isPointInFill fill?
Activity
dirkschulze commentedon Apr 20, 2018
Currently only Chrome seem to support
isPointInFill. It ignores the settings ofvisibilityorpointer-eventsentirely. It does not even take clipping paths into account: https://codepen.io/krit/pen/BxNqWvIt needs to get checked if it respects winding rules set by
fill-ruleat least.Link to the spec: https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement
dirkschulze commentedon Apr 20, 2018
@heycam Do you recall the intention of the functions?
AmeliaBR commentedon Apr 20, 2018
I don't see any reason for having these functions depend on the
pointer-eventssetting. These methods are about giving authors more control thanpointer-eventsallows.dirkschulze commentedon Apr 21, 2018
I think the idea was that the
isPointIn*methods were supposed to respect clipping applied to the shape likepointer-eventsdo. Furthermore, this was probably easier to describe than redefining which winding rule to use when? (clip-rulewhen the shape is child of<clipPath>andfill-ruleotherwise.)However, then again, hit testing on a shape within a
<clipPath>can't happen anyway. So would those methods returnfalseall the time in this case?Also, should it matter if
visibilitygets applied on a shape or not?I would prefer that those functions operate as independent of the context the element lives in. Independent where they are and independent if they get clipped or not. However, what about the winding rule? Add an optional additional argument in
isPointInFillfor the winding rule instead of magically choosingclip-ruleoverfill-rule?css-meeting-bot commentedon May 7, 2018
The Working Group just discussed
Clarify relation of isPointInFill and pointer-events, and agreed to the following:RESOLVED: isPointInStroke/Fill methods shouldn't be affected by current value of pointer-events propertyRESOLVED: Use the pointer-events algorithms for defining which areas are fill and which are stroke, EXCEPT for ignoring clippingThe full IRC log of that discussion
<BogdanBrinza> topic: Clarify relation of isPointInFill and pointer-events<BogdanBrinza> GitHub: https://github.com//issues/416
<AmeliaBR> scribenick: AmeliaBR
<krit> https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement
<AmeliaBR> Dirk: The specification isn't clear about how isPointInFill/Stroke should be calculated?
<AmeliaBR> ... in particular, what does it mean that "normal hit testing rules apply" with respect to pointer-events property
<AmeliaBR> https://svgwg.org/svg2-draft/interact.html#PointerEventsProp
<AmeliaBR> ... the way it's written, it suggests that the point would return false if pointer events setting would make it not sensitive
<AmeliaBR> ... I don't think we should take the pointer events property into account at all
<AmeliaBR> ... if its none, the method would always return false; if bounding-box, would all parts of the box be both fill and stroke? It doesn't make sense
<AmeliaBR> Amelia: I agree, as written it doesn't make sense. Not sure of original intent. Maybe the intention was to reference some of the algorithms in the pointer-events section.
<AmeliaBR> Dirk: Maybe it would make sense to say that isPointInStroke should include all points that would be sensitive with pointer-events: stroke.
<AmeliaBR> ... If we follow that definition, however, it would mean that it would be affected by clip-paths.
<AmeliaBR> ... There are also confusion about shapes in <defs>. They don't have pointer-events, but they could still use this interface.
<AmeliaBR> (or children of pattern, clipPath, mask, etc.)
<AmeliaBR> ... The current Chrome implementation isn't affected by whether the shape is rendered or clipped.
<krit> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-ispointinpath
<AmeliaBR> ... Results are similar to the canvas isPointInPath API, although that also takes a winding-order (equivalent to fill-rule)
<AmeliaBR> Amelia: So, if we don't have that parameter, we need to use the fill-rule on the element?
<krit> https://drafts.fxtf.org/css-masking-1/#the-clip-rule
<AmeliaBR> Dirk: Yes, but for children of a clipPath, the relevant property is clip-rule.
<AmeliaBR> Amelia: That's a pain. We have these two properties that do the same thing, but which to use depends on context.
<AmeliaBR> Dirk: So, first question: Do we agree that the pointer-events property on the element shouldn't affect the API results?
<AmeliaBR> RESOLVED: isPointInStroke/Fill methods shouldn't be affected by current value of pointer-events property
<AmeliaBR> Dirk: Next question is how do we calculate it?
<AmeliaBR> Dirk: My general suggestion is to align with HTML canvas spec.
<AmeliaBR> Amelia: Do you know implementation status for the canvas methods?
<AmeliaBR> Dirk: I did WebKit, a colleague did Gecko, Blink has it as well.
<dstorey> https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?page=1&q=isPointIn <- browser support
<AmeliaBR> Amelia: So essentially, the canvas API is fixed
<AmeliaBR> Dirk: The downside is that we then can't set it up to automatically match clip-rule
<AmeliaBR> Amelia: But the canvas API accepts a parameter when you call the method, so we could extend our method as well, if an author wanted to query the clip-rule and pass it to the method.
<AmeliaBR> Liam: But we could probably add that later, right? It doesn't have to be now.
<AmeliaBR> Dirk: Probably
<AmeliaBR> Dirk: It's not just clip-rule, it's also parent clip-path
<AmeliaBR> Amelia: Oh, I see. Yes, I agree to keep the simpler approach for now.
<AmeliaBR> ... We could later extend it by adding an options object, similar to the proposed options for getBBox()
<AmeliaBR> Dirk: I'd still recommend we use the pointer-events algorithm (for fill versus stroke), just with not taking clipping paths into account
<AmeliaBR> Amelia: Can you come up with a draft text for review?
<AmeliaBR> Dirk: Yes
<AmeliaBR> RESOLVED: Use the pointer-events algorithms for defining which areas are fill and which are stroke, EXCEPT for ignoring clipping
<AmeliaBR> Dirk to create proposal
Specify algorithm used for isPointInFill() and isPointInStroke(). #416
Merge pull request #443 from w3c/clarify-isPointInFillStroke