Clarify relation of isPointInFill and pointer-events

[dirkschulze]

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-events property 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?

[dirkschulze]

Currently only Chrome seem to support isPointInFill. It ignores the settings of visibility or pointer-events entirely. It does not even take clipping paths into account: https://codepen.io/krit/pen/BxNqWv

It needs to get checked if it respects winding rules set by fill-rule at least.

Link to the spec: https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement

[dirkschulze]

@heycam Do you recall the intention of the functions?

[AmeliaBR]

I don't see any reason for having these functions depend on the pointer-events setting. These methods are about giving authors more control than pointer-events allows.

[dirkschulze]

I think the idea was that the isPointIn* methods were supposed to respect clipping applied to the shape like pointer-events do. Furthermore, this was probably easier to describe than redefining which winding rule to use when? (clip-rule when the shape is child of <clipPath> and fill-rule otherwise.)

However, then again, hit testing on a shape within a <clipPath> can't happen anyway. So would those methods return false all the time in this case?

Also, should it matter if visibility gets 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 isPointInFill for the winding rule instead of magically choosing clip-rule over fill-rule?

[css-meeting-bot]

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 property
• RESOLVED: Use the pointer-events algorithms for defining which areas are fill and which are stroke, EXCEPT for ignoring clipping

The 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