Resolved value for the 'width' and 'height' geometry properties

[fsoder]

Should the 'resolved value' [1] for the 'width' and 'height' geometry properties [2] be the computed value or the used value?
Per CSSOM [1] it would be the 'used value' - under the assumption that the properties in question "apply to" the relevant element (for example <rect> and <image>), which isn't explicitly stated in the spec (AFAICS), but seems reasonable to assume given existing definitions.
I guess one could also argue that the 'used value' is the resolved value at all is because of legacy constraints, and so we don't need have these "new uses" follow those legacy rules.
AFAIK, no UA returns 'used value's in the relevant cases at the moment.

[1] https://drafts.csswg.org/cssom-1/#resolved-values
[2] https://svgwg.org/svg2-draft/geometry.html#Sizing

[AmeliaBR]

To clarify: the used value is different from the computed value for CSS boxes because layout snaps the dimensions to fit the pixel grid? So, for SVG elements, this would only be an issue when using shape-rendering: crispEdges?

[fsoder]

No, this would more be about whether percentages (and 'auto') are resolved or not.

[AmeliaBR]

OK, sorry. I was getting "used values" confused with "actual values" in CSS's complicated series of value-resolution terms.

For any API that is reporting a used value where values are resolved to px for width and height on CSS layout boxes, I would expect the same for any SVG elements where the properties apply. Consistency should outweigh theoretical purity. I suspect it was overlooked in the initial geometry property implementations, so they are still coded as if width and height don't apply to the element & therefore there is no "used value".

The next question is, for the other SVG geometry properties, should they be explicitly made to match the width/height behavior (resolve to px), or should they report the computed value (with units, percentage, or auto)?

[fsoder]

...other SVG geometry properties, should they be explicitly made to match the width/height behavior...

Considering the "legacy constraints" / "historical reasons" (mentioned) above, I would probably suggest to leave them as 'computed value'. I'd welcome other inputs here though. (The usual "con" for 'used value' tend to be that they require layout - which browsers tend to try to avoid doing if they can. In these case I don't think layout is strictly needed yet - except maybe for 'auto' on <image>.)

[AmeliaBR]

In these case I don't think layout is strictly needed yet.

Sometimes it would be. Percentages in SVG geometry are relative to the coordinate system. If the nearest viewport element (<svg> or <symbol>) has a viewBox, that's a fixed value determined from the DOM, without layout. But if it's an <svg> without a viewBox, then it's based on the actual dimensions of the SVG's layout box, which could require a full layout. And as you say, auto for an <image> would require access to the intrinsic dimensions of the image.

The only other complicated situation is rx and ry: they have auto values (meaning, match the other property) and also clamping on rectangles (although I think that would count as an "actual value" calculation, not a "used value"). I just re-read the spec text for rx and ry, and we specifically say "used value" for the clamping.

[fsoder]

Yes, you're right about the "<svg> without viewBox or fixed dimensions" - that could be enough hassle to detect to just make it easier to implement as "needs layout" in general. rx and ry sounds like they could be tricky (you essentially need both rx, ry, width and height to be able to get the used value.)

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

[css-meeting-bot]

The SVG Working Group just discussed Resolved value for the 'width' and 'height' geometry properties.

The full IRC log of that discussion

<myles> Topic: Resolved value for the 'width' and 'height' geometry properties
<myles> GitHub: https://github.com//issues/349
<myles> AmeliaBR: This has to do with what you get back from getComputedStyle().
<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
<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.,
<myles> AmeliaBR: And the rest of the comments in the issue are what happens on what stage in the CSS process for different properties.
<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.
<myles> AmeliaBR: The question is if the resolved value only exists if the element applies
<myles> krit: Like if you have a circle with width=%, what does getComputedStyle() return?
<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
<myles> ericwilligers: Can't we just preserve percentages?
<AmeliaBR> https://drafts.csswg.org/cssom-1/#resolved-value
<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
<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.
<myles> krit: Then it says "otherwise"
<myles> krit: So for the circle, all those apply
<myles> AmeliaBR: Width doesn't apply to a circle.
<myles> AmeliaBR: We have to be consistent with weird legacy rules.
<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?
<myles> krit: So usually it's the used value or the computed value?
<myles> krit: which one is which?
<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.
<myles> krit: Are there properties that take a width percentage which have been added after CSS2 which are different from width and height
<myles> AmeliaBR: The logical properties. Inline-size, block-size margin-end
<myles> AmeliaBR: in those properties, it was decided to keep consistent
<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
<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.
<myles> krit: But we did testing for the other properties in other implementations. They are following the SVG 2 spec text currently.
<myles> krit: Was it correct?
<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.
<myles> krit: So it would be a change to both specification and implementations for the geometry properties.
<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?
<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.
<myles> AmeliaBR: It's a matter of testing, rather than specs
<myles> krit: Is there an interest to chagne geometry properties to follow width and height computed style?
<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
<myles> krit: it will be more confusing if we change that part now
<myles> ericwilligers: I'll add tests
<myles> myles: We should keep what is implemented
<myles> krit: Give ericwilligers's tests we can see what is implemented.
<myles> AmeliaBR: Sounds good.
<myles> AmeliaBR: ericwilligers, please ping someone from CSS to make sure it is reviewed and correct
<myles> krit: We are out of time.
<myles> krit: anyting else?
<myles> <silence>
<myles> AmeliaBR: We agreed one more meeting this month, next week, and then 2 weeks off.
<myles> krit: Okay, bye!
<myles> myles: 👋
<krit> trackbot, end telcon

[dirkschulze]

@AmeliaBR @fsoder I created a little test case https://codepen.io/krit/pen/KbpmJv Unless I made a mistake, all geometry properties, even width and height, return the computed value in WebKit and Blink (50% on all properties).

edit: FYI WebKit does not apply rx and ry on the <rect> element it seems.

[fsoder]

Yes, that looks as expected (for Blink) AFAIK. (I have a pending change to fix https://crbug.com/772707 waiting on this issue.)

[dirkschulze]

@fsoder Sounds like you want to follow CSSOM on width and height. We discussed the issue in the call and don't see that we would need to change the specification to get the specified behavior of CSSOM. The other properties keep the "computed value" for computed style. Anything else that needs to be discussed?

[fsoder]

Not changing spec (relying on CSSOM) sounds fine to me. I don't see that anything else needs to be discussed here, so i'll close the issue now.