[css-sizing] Define sizing of SVG Boxes with intrinsic aspect-ratio but no intrinsic size, in an auto-sized shrink-wrap parent

[FremyCompany]

If 'height' and 'width' both have computed values of 'auto' and the element has an intrinsic ratio but no intrinsic height or width, then the used value of 'width' is undefined in CSS 2.2.
However, it is suggested that, if the containing block's width does not itself depend on the replaced element's width, then the used value of 'width' is calculated from the constraint equation used for block-level, non-replaced elements in normal flow.
https://drafts.csswg.org/css2/visudet.html#inline-replaced-width

Browsers seem to follow the recommendation when it applies, but the undefined behavior is not 100% interoperable though most browsers (Edge / Chrome / Safari) seem to fallback to the "default object width" and compute the height using the aspect ratio.

https://jsfiddle.net/2y31ru8u/

Maybe time to define an actual behavior?
cc @dbaron @fantasai

[FremyCompany]

For completeness, Firefox behavior looks like to take the width of the last containing block that has a definite width (or the viewport). Looks like Edge and Chrome cap the object default width at that, but do not go higher. Might need more tests.

https://jsfiddle.net/2y31ru8u/1/

[frivoal]

I don't remember all the details, but I looked into similar questions of that when defining box-sizing and writing tests for it. If you're planing on writing tests on this topic, it could be worth looking at these for inspiration.

[fantasai]

It seems like Firefox's behavior is the most author-friendly. If @dbaron can explain how it works and convince everyone to follow, Tab and I think that would be the best course of action.

[dbaron]

The Firefox behavior is fundamentally broken and shouldn't be copied.

But it's possible that using an infinite max-content width will do what you want. But also see #1046.

[fantasai]

Infinite max-content width seems a bit problematic to render if someone explicitly requests it. :) But how about using the nearest scrollport width? That will nearly always be larger than the containing block width when you're doing shrink-to-fit, so will behave the same as infinity, but if you request it explicitly it'll still be a reasonable size. (This is also consistent with how we handle orthogonal flows when we need a size but don't have one.)

[dbaron]

Intrinsic size computation can cross scrollports, so I don't think that works. The size of the scrollport might be a function of the intrinsic size of one of its ancestors, which was influenced by content inside the scrollport.

[fantasai]

Good point. We need to resolve on something definite for #1391 regardless, though, so once we figure that out we could use the same solution here.

[fantasai]

Possible solutions that have been suggested

• Use the ICB size (problem is with nested scroll containers, this isn't helpful)
• From nearest fixed size container, subtract out margin/border/padding of intervening elements (dbaron's stretch-fit algo). Problem is this might give us way too little space in a deeply nested context that reaches out to the viewport.
• Use the nearest container with a fixed size (problem is that this isn't particularly related to how much content can be seen, might be significantly more or less)
• Use the nearest scroll container with a fixed size (nice because nearest scrollport determines how much content can be seen, so good for UX)

I'm thinking nearest fixed-size scrollport is the best option (for this and the WM issue linked above).