- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Nov 2018 22:01:34 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `isPointInFill/isPointInStroke and display: none and other specifics`, and agreed to the following: * `RESOLVED: Elements that "do not get rendered" may not correct the correct, expected value for methods that require calculating the geometry of an element. (Does not include getCTM() or getScreenCTM())` * `RESOLVED: Elements that "do not get rendered" may not correct the correct, expected value for methods that require calculating the geometry of an element. (Also includes getCTM() or getScreenCTM())` * `RESOLVED: getCTM(), getScreenCTM() return null in this situation, everything else throws a to-be-determined exception in this situation.` <details><summary>The full IRC log of that discussion</summary> <myles> TOPIC: isPointInFill/isPointInStroke and display: none and other specifics<br> <myles> Github: https://github.com/w3c/svgwg/issues/456<br> <myles> krit: This is a more general issue that gets more visible with the new presentation attributes, x, y, widht, height, etc. that we have for geometry objects. To describe the issue, we have interfaces like isPointInFill, isPointInStroke, getBBox, that is supposed to return values independent of the state of teh element (like if it's attached to the DOM)<br> <myles> krit: the reality is that firefox can't return correct results if it's display none. But with the presetnation attributes on geometry attribute,s the same issue comes up on WebKit and blink, which is an implemetation detail, both are not able to provide correct results if you have display:none or its' not attached tot he DOM<br> <myles> krit: The proposal is we allow UAs in certain situations to not return the correct result. First we need to agree to allow UAs to not return the correct results in certain situations.<br> <myles> krit: I think it was a proposed text from emilio which is "if a UA is not able to lay out an element, it would need to return an incorrect result for these interfaces" and the spec would give non-normative examples with display:none, or elements not attached to the dom tree.<br> <myles> krit: Example: <rect> w/ width= and height=, those are now CSS properties, so if you have display:none, none of the browsers would be able to compute the dimension of the <rect>. Implementation detail but that's a fact.<br> <ericwilligers> Why not say that we throw if display is none or the element is not attached?<br> <myles> krit: I would like to specify that for all those interfaces there are exceptions where UAs would not need to return the correct value.<br> <myles> myles: I'm worried about using the term "lay out" normatively in a psec. Let's gather more specific requirements for when the result can be wrong?<br> <myles> ericwilligers: why not just throw?<br> <myles> krit: that's not the question.<br> <myles> krit: myles - i agree it would be cool to specify them, but optimization steps might not allow it. So we can't be specific about the entire collection, we can't use "might" or "may", it might work as well<br> <myles> AmeliaBR: defs shouldn't be treated differently than any other case of display:none<br> <myles> AmeliaBR: The way we define how defs work in SVG 2 is it forces display:none<br> <myles> AmeliaBR: so it shouldn't be different.<br> <myles> AmeliaBR: there shouldn't be a difference between author display:none and automatically display:none<br> <myles> krit: we could say "elements that don't get rendered"<br> <myles> AmeliaBR: visible:hidden is different.<br> <myles> krit: yeah, we woul dneed to specify what "Rendering" means<br> <myles> AmeliaBR: that is specified. we have definitions what it means for elements not to be rendered.<br> <myles> krit: can we use this term? UAs may return on elements that do not get rendered?<br> <myles> AmeliaBR: yeah<br> <myles> ericwilligers: Can't we just say the 3 cases: display:none, <defs>, and is that it?<br> <myles> ericwilligers: or its' not attached<br> <myles> ericwilligers: and I suggest we should throw<br> <myles> krit: In CSS we already ahve a term that describes those cases, so we can use that term<br> <myles> RESOLVED: Elements that "do not get rendered" may not correct the correct, expected value for methods that require calculating the geometry of an element. (Does not include getCTM() or getScreenCTM())<br> <myles> AmeliaBR: transforms are separate from geometry, I guess.<br> <myles> RESOLVED: Elements that "do not get rendered" may not correct the correct, expected value for methods that require calculating the geometry of an element. (Also includes getCTM() or getScreenCTM())<br> <myles> AmeliaBR: wait, no no no no<br> <myles> AmeliaBR: you don't need geometry to calculate the CTM!!!<br> <myles> krit: You probably want the transform properties to get the CTM.<br> <myles> AmeliaBR: Darn it.<br> <myles> AmeliaBR: okay.<br> <myles> krit: what about getCTM() and getScreenCTM()? In some situation, they already return null. How about we use this behavior for the above situations, too?<br> <myles> krit: So getCTM() and getScreenCTM() would return null for these situations, and we still have to decide on the tohers.<br> <myles> s/tohers/others/<br> <myles> AmeliaBR: My strong feeling is that it should return something that is obviously not available, and can't be mistaken for a correct value<br> <myles> s/correct value/real result that is not the correct result/<br> <myles> krit: Firefox throws already (NSError, an internal error...) I don't see any interop problems here.<br> <myles> krit: getBBox() already throws in Firefox, so there's probably no issue<br> <myles> ericwilligers: getTotalLength() will also probably have to throw.<br> <myles> krit: agreed.<br> <myles> krit: can we resolve on those methods that are not able to return null would throw?<br> <myles> AmeliaBR: the other option is to return NaN<br> <myles> AmeliaBR: or a BBox with all values set to NaN<br> <myles> krit: that doesn't require a try catch<br> <myles> AmeliaBR: it might be cleaner to have a try catch<br> <myles> myles: let's not use NaNs because they are silently propagated<br> <myles> krit: sounds like we prefer throwing.<br> <myles> AmeliaBR: Firefox is already throwing, so there's precident<br> <myles> AmeliaBR: Any preferences for which error to throw? Or we could send it back to Github<br> <myles> krit: Let's make a PR and discuss it there.<br> <myles> krit: That's what HTML does.<br> <myles> krit: We are out of time.<br> <myles> RESOLVED: getCTM(), getScreenCTM() return null in this situation, everything else throws a to-be-determined exception in this situation.<br> <myles> krit: If you have issues, please add the label on the Github issue.<br> <myles> krit: Thank you much for calling in!<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-438043664 using your GitHub account
Received on Monday, 12 November 2018 22:01:35 UTC