- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Dec 2018 22:01:50 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `Resolved value for the 'width' and 'height' geometry properties`. <details><summary>The full IRC log of that discussion</summary> <myles> Topic: Resolved value for the 'width' and 'height' geometry properties<br> <myles> GitHub: https://github.com/w3c/svgwg/issues/349<br> <myles> AmeliaBR: This has to do with what you get back from getComputedStyle().<br> <myles> AmeliaBR: In general, for CSS width and height, if you do getComputedStyle() and the element's width and height actually apply to it, then percentages and keywords get converted to final px values. But if you do it on an element where width and height dont' have meaning, then you get the partially-simplified version, because there is nothing that can convert percentages. The people who implemented width and height on svg <rect> didn't change how<br> <myles> getCOmputedStyle() works on these, so I think as far as spec changes, as soon as we say that width and height to <rect> and <image> then based on the rules in CSS, getComputedStyle() should convert everything to final absolute values. But its' a case on needing to follow up on implementations.,<br> <myles> AmeliaBR: And the rest of the comments in the issue are what happens on what stage in the CSS process for different properties.<br> <myles> krit: when you look at CSSOM, it doesn't seem to differ between objects which make meaning of width and height and which don't. It just has special case for display:none.<br> <myles> AmeliaBR: The question is if the resolved value only exists if the element applies<br> <myles> krit: Like if you have a circle with width=%, what does getComputedStyle() return?<br> <myles> AmeliaBR: On a circle, width doesn't apply, so you get back what you specified. But if it was a <rect> then you get px<br> <myles> ericwilligers: Can't we just preserve percentages?<br> <AmeliaBR> https://drafts.csswg.org/cssom-1/#resolved-value<br> <myles> AmeliaBR: It depends on the property and whether or not the percentage can be resolved. It's illogical legacy in CSS but hey that's what we have<br> <myles> AmeliaBR: For margin, padding, height, width, if the property applies to the element or the pseudo element, and it's being displayed, you have to resolve down to the used value, which is px.<br> <myles> krit: Then it says "otherwise"<br> <myles> krit: So for the circle, all those apply<br> <myles> AmeliaBR: Width doesn't apply to a circle.<br> <myles> AmeliaBR: We have to be consistent with weird legacy rules.<br> <myles> AmeliaBR: Width and height are already in CSS, so they already have these legacy rules. What about the other SVG geometry properties where we don't have a legacy issue that we have to treat them this way but do we want to treat them this way anyway so they're consistent with width and height?<br> <myles> krit: So usually it's the used value or the computed value?<br> <myles> krit: which one is which?<br> <myles> AmeliaBR: the resolved value, which is the return of getComputedStyle(), is a special case, it would return the used value if the property applies to the element. So if you getComputedStyle of "R" on a circle, if we opted in to these rules, it would convert percentages to px.<br> <myles> krit: Are there properties that take a width percentage which have been added after CSS2 which are different from width and height<br> <myles> AmeliaBR: The logical properties. Inline-size, block-size margin-end<br> <myles> AmeliaBR: in those properties, it was decided to keep consistent<br> <myles> krit: So we would have to do something about resolved value of the computed style, how it serializes to a computed style, for x, y, cx, cy, rx, ry<br> <myles> AmeliaBR: we don't have to write a lot of extra spec text. We have to say the resolved value for the geometry properties behave like this example. And tests to back it up. And they're not implemented that way so we need to follow up with implementations.<br> <myles> krit: But we did testing for the other properties in other implementations. They are following the SVG 2 spec text currently.<br> <myles> krit: Was it correct?<br> <myles> AmeliaBR: SVG 2 didn't say anything about it, so they did the CSS thing, which is to return the computed value not the used values.<br> <myles> krit: So it would be a change to both specification and implementations for the geometry properties.<br> <myles> krit: So let's keep it for width and height specifically. The text is already there in CSSOM. So, is there anything we need to resolve on?<br> <myles> krit: Unless we say the geometry properties should behave like width and height, there's nothing to change because it's already covered and implemented.<br> <myles> AmeliaBR: It's a matter of testing, rather than specs<br> <myles> krit: Is there an interest to chagne geometry properties to follow width and height computed style?<br> <myles> AmeliaBR: From a user's perspective, I find it helpful if they were consistent. From a spec perspective, the spec should say what browsers already do<br> <myles> krit: it will be more confusing if we change that part now<br> <myles> ericwilligers: I'll add tests<br> <myles> myles: We should keep what is implemented<br> <myles> krit: Give ericwilligers's tests we can see what is implemented.<br> <myles> AmeliaBR: Sounds good.<br> <myles> AmeliaBR: ericwilligers, please ping someone from CSS to make sure it is reviewed and correct<br> <myles> krit: We are out of time.<br> <myles> krit: anyting else?<br> <myles> <silence><br> <myles> AmeliaBR: We agreed one more meeting this month, next week, and then 2 weeks off.<br> <myles> krit: Okay, bye!<br> <myles> myles: 👋<br> <krit> trackbot, end telcon<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/349#issuecomment-445991085 using your GitHub account
Received on Monday, 10 December 2018 22:01:52 UTC