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