- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 Jul 2018 20:34:35 +0000
- To: public-svg-issues@w3.org
The Working Group just discussed `isPointInFill/isPointInStroke`. <details><summary>The full IRC log of that discussion</summary> <AmeliaBR> Topic: isPointInFill/isPointInStroke<br> <AmeliaBR> GitHub: https://github.com/w3c/svgwg/issues/456<br> <AmeliaBR> Dirk: First question, is this new in SVG 2 or was it an extension from 1.1?<br> <AmeliaBR> Amelia: It's new in SVG 2. And we've got a couple implementations, so it should stay.<br> <AmeliaBR> Dirk: OK, then we need to clean up these questions.<br> <AmeliaBR> ... question is whether it can return valid values in certain conditions, like display: none<br> <AmeliaBR> ... Blink and Webkit always return false in these cases, and there are implementation reasons that make it difficult to work around.<br> <AmeliaBR> ... Geometry is defined by CSS properties, and those properties aren't fully computed for a display: none element.<br> <AmeliaBR> ... likely to affect Firefox, too, when they implement CSS properties.<br> <AmeliaBR> Amelia: We don't want to spec something that can't be implemented. But don't want to give up without even looking into implementation options.<br> <AmeliaBR> ... I really don't like returning false in this case, though. Better to throw an error if geometry can't be computed.<br> <AmeliaBR> Dirk: One complication is that SVG 1.1 didn't have any exceptions for display: none, so wouldn't this be a breaking change?<br> <AmeliaBR> Amelia: The isPointInFill/Stroke methods weren't in 1.1, so that's not an issue. But it would be an issue for getBBox, which has the same complications for geometry and was in 1.1.<br> <AmeliaBR> ... but Firefox did have a bug with that (not returning valid BBox values for non-rendered elements), so it may never have been *fully* web compatible.<br> <AmeliaBR> Dirk: Good point. Blink & webkit used to have no problem with that, but now that they support d etc in CSS, there are inherited problems in the render tree.<br> <AmeliaBR> ... Multiple ways to address this:<br> <AmeliaBR> ... could say that the behavior is not defined<br> <AmeliaBR> ... could say to throw an error if shape cannot be computed, leave it to implementations to decide when that case it exists<br> <AmeliaBR> ... or we could explicitly define which cases a shape cannot be computed.<br> <AmeliaBR> Amelia: I like your second option. Clearly define an error behavior if the shape cannot be computed, but leave it undefined in this spec when that will occur. Wait for implementation feedback, see if we get a consistent pattern.<br> <AmeliaBR> Dirk: By error behavior, you mean the method throws an error?<br> <AmeliaBR> Amelia: Yes.<br> <AmeliaBR> Dirk: Which error?<br> <AmeliaBR> Amelia: I don't know. We'd need to review the error classes, see if one makes sense.<br> <AmeliaBR> Dirk: OK, we can look into that later.<br> <AmeliaBR> Amelia: One issue, if we wanted to extend that behavior to getBBox, that would change the definition of an existing method so that it can now throw errors. That could be a compatibility issue.<br> <AmeliaBR> Amelia: We could make a tentative resolution, but I'd like to get feedback from implementer teams.<br> <AmeliaBR> Dirk: I'm off the next few weeks, but I'll try to run some tests in WebKit when I get back.<br> <AmeliaBR> Dirk: Separate issue is, what if there is no fill or is no stroke? That's also not defined.<br> <AmeliaBR> Amelia: Did you test the current implementations?<br> <AmeliaBR> Dirk: Neither Blink nor Webkit compute the stroke shape when stroke is none. For fill, Blink doesn't , WebKit does (but that can be changed easily).<br> <AmeliaBR> Amelia: As I mentioned in spec, with pointer-events we can have pointer-sensitive stroke even if it is not painted. So the browsers need to do the calculations for hit testing, would expect the DOM method to work, too.<br> <AmeliaBR> Dirk: I will try to look into what WebKit does in that case, and update the issue.<br> <AmeliaBR> Amelia: Also hope to get other implementer feedback. Maybe @ewilligers can look into Blink.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/456#issuecomment-407192082 using your GitHub account
Received on Monday, 23 July 2018 20:34:38 UTC