Re: [svgwg] Clarify relation of isPointInFill and pointer-events

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;BogdanBrinza> topic: Clarify relation of isPointInFill and pointer-events<br>
&lt;BogdanBrinza> GitHub: https://github.com/w3c/svgwg/issues/416<br>
&lt;AmeliaBR> scribenick: AmeliaBR<br>
&lt;krit> https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement<br>
&lt;AmeliaBR> Dirk: The specification isn't clear about how isPointInFill/Stroke should be calculated?<br>
&lt;AmeliaBR> ... in particular, what does it mean that "normal hit testing rules apply" with respect to pointer-events property<br>
&lt;AmeliaBR> https://svgwg.org/svg2-draft/interact.html#PointerEventsProp<br>
&lt;AmeliaBR> ... the way it's written, it suggests that the point would return false if pointer events setting would make it not sensitive<br>
&lt;AmeliaBR> ... I don't think we should take the pointer events property into account at all<br>
&lt;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<br>
&lt;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.<br>
&lt;AmeliaBR> Dirk: Maybe it would make sense to say that isPointInStroke should include all points that would be sensitive with pointer-events: stroke.<br>
&lt;AmeliaBR> ... If we follow that definition, however, it would mean that it would be affected by clip-paths.<br>
&lt;AmeliaBR> ... There are also confusion about shapes in &lt;defs>. They don't have pointer-events, but they could still use this interface.<br>
&lt;AmeliaBR> (or children of pattern, clipPath, mask, etc.)<br>
&lt;AmeliaBR> ... The current Chrome implementation isn't affected by whether the shape is rendered or clipped.<br>
&lt;krit> https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-ispointinpath<br>
&lt;AmeliaBR> ... Results are similar to the canvas isPointInPath API, although that also takes a winding-order (equivalent to fill-rule)<br>
&lt;AmeliaBR> Amelia: So, if we don't have that parameter, we need to use the fill-rule on the element?<br>
&lt;krit> https://drafts.fxtf.org/css-masking-1/#the-clip-rule<br>
&lt;AmeliaBR> Dirk: Yes, but for children of a clipPath, the relevant property is clip-rule.<br>
&lt;AmeliaBR> Amelia: That's a pain. We have these two properties that do the same thing, but which to use depends on context.<br>
&lt;AmeliaBR> Dirk: So, first question: Do we agree that the pointer-events property on the element shouldn't affect the API results?<br>
&lt;AmeliaBR> RESOLVED: isPointInStroke/Fill methods shouldn't be affected by current value of pointer-events property<br>
&lt;AmeliaBR> Dirk: Next question is how do we calculate it?<br>
&lt;AmeliaBR> Dirk: My general suggestion is to align with HTML canvas spec.<br>
&lt;AmeliaBR> Amelia: Do you know implementation status for the canvas methods?<br>
&lt;AmeliaBR> Dirk: I did WebKit, a colleague did Gecko, Blink has it as well.<br>
&lt;dstorey> https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/?page=1&amp;q=isPointIn &lt;- browser support<br>
&lt;AmeliaBR> Amelia: So essentially, the canvas API is fixed<br>
&lt;AmeliaBR> Dirk: The downside is that we then can't set it up to automatically match clip-rule<br>
&lt;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.<br>
&lt;AmeliaBR> Liam: But we could probably add that later, right? It doesn't have to be now.<br>
&lt;AmeliaBR> Dirk: Probably<br>
&lt;AmeliaBR> Dirk: It's not just clip-rule, it's also parent clip-path<br>
&lt;AmeliaBR> Amelia: Oh, I see. Yes, I agree to keep the simpler approach for now.<br>
&lt;AmeliaBR> ... We could later extend it by adding an options object, similar to the proposed options for getBBox()<br>
&lt;AmeliaBR> Dirk: I'd still recommend we use the pointer-events algorithm (for fill versus stroke), just with not taking clipping paths into account<br>
&lt;AmeliaBR> Amelia: Can you come up with a draft text for review?<br>
&lt;AmeliaBR> Dirk: Yes<br>
&lt;AmeliaBR> RESOLVED: Use the pointer-events algorithms for defining which areas are fill and which are stroke, EXCEPT for ignoring clipping<br>
&lt;AmeliaBR> Dirk to create proposal<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/416#issuecomment-387168170 using your GitHub account

Received on Monday, 7 May 2018 19:00:39 UTC