[css-sizing-3] Ratio-constrained elements in definite-sized Grid/Flexbox containers

[tabatkins]

Currently when we have an image with an intrinsic aspect ratio but not intrinsic size, we calculate its max-content size using the inline axis of the containing block.

But for flex and grid, it might be better to use a contain-fit into both axises at once, using
a) the track/line if that is definite
b) else the container size, if that is definite
c) else infinity
If both axes are infinity, then fall back through the bullet list in Sizing 3 §4.1

(Block layout would always skip to c (infinity) for the block axis constraint, as that's the current behavior in many aspects of block layout already.)

Example where the current behavior is bad:

<div style="display: flex; flex-flow: row wrap; height: 100px; border: thick dotted; width: 220px; align-self: flex-start;">
  <svg viewBox="-1 -1 2 2" style="background: blue; flex-shrink:0">
    <circle r="1" fill="pink"/>
  </svg>
</div>

(Firefox is currently spec-compliant in this case. Chrome, for some reason, doesn't size the SVG to the available 220px, but instead lets it grow to 300px wide.)

Here, the image is sized to the available inline space (220px), and then transfers that across its aspect-ratio so it's 220px tall as well.

We suspect the better, more expected behavior would be to contain-fit the image into the available space (220x100), which would result in a 100x100 element.

Similarly, if the flexbox was only 50px wide, the contain-fit would make it 50px wide, and then the aspect-ratio would make it 50px tall, which again seems to be the more expected behavior.

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing-3] Ratio-constrained elements in definite-sized Grid/Flexbox containers.

The full IRC log of that discussion

<dael> Topic: [css-sizing-3] Ratio-constrained elements in definite-sized Grid/Flexbox containers
<dael> github: https://github.com//issues/5317
<dael> TabAtkins: Little complicated
<dael> TabAtkins: Currently if you have a ratio-constrained element like and image, we put in grid of flexbox which are def. sized. Rule for ratio end up basing element sizing on inline axis
<bkardell_> prsent+
<dael> TabAtkins: In the example in the issue elements are [missed] and element is 1:1 ratio. Sizes to container and maxes it 220px high
<dael> TabAtkins: In example container is 220px wide 100 tall. Default is base on inline axis. 200px wide and transfers across ratio and overflows. We believe more expected is in case where both sizes are definite contain into them. Base on the smaller one. Becomes 100x100 which makes the smaller row
<Guest60> present-
<dael> TabAtkins: Current behavior in this case is inconsistent. No one does what we suggest. Chrome doesn't do what spec says either, though.
<dael> TabAtkins: Call for impl to check this out and see if they think it's reasonable. We think better in general but not certain
<dael> TabAtkins: Don't need resolve, but need impl to look.
<dael> ??: Why would this size to full available since elements usually shrink to fit
<astearns> s/??/cbiesinger/
<dael> AmeliaBR: svg in general if you have inline with no other constraints it fits available width. Just block layout behavior
<Rossen_> q?
<dael> AmeliaBR: Also comes from original svg spec which is svg w/o sizing fills 100% in each direction. If it's inside css layout we put constraints on that so it doesn't take page. only fills width if it has a-r
<dael> AmeliaBR: Brings quesiton if it has clearly defined available height should that factor in. I think probably reasonable and useful behavior that it does. Whichever dimension is the clearly defined one, that's what it fills. Than a0r is opposite dimension
<dael> AmeliaBR: Question becomes can we define consistent w/o special cases
<dael> iank_: What happens today with similar svgs?
<dael> AmeliaBR: Last I checked not consistent
<dael> fantasai: IN spec if length for min we use that, if not 300x150. Maybe just 300
<dael> dholbert: How to determine flex base size?
<dael> fantasai: Yes
<dael> TabAtkins: And similarly for grid
<dael> cbiesinger: Seems specific to svg unlike generic summary
<dael> TabAtkins: Any image that can have ratio but not width and height which is only svg
<dael> AmeliaBR: svg or svg linked from image element
<dael> fantasai: with a-r same behavior will end up being relevent
<dael> AmeliaBR: Good point
<dael> cbiesinger: a-r has inline style based on contents, right?
<dael> fantasai: true
<dael> Rossen_: Sounds like a number of cases to consider
<cbiesinger> s/style/size/
<dael> Rossen_: Do we comfortable with an approach or do we take for more details in the issue? Was intent to just introduce, TabAtkins , or get resolution?
<dael> TabAtkins: I got what I wanted
<dael> Rossen_: Then I suggest we move on and continue in issue

[cbiesinger]

So as discussed, this only affects SVGs. (other elements with an intrinsic aspect ratio always have sizes, and when using the aspect-ratio property we calculate this based on their intrinsic width (max-content size)).

And SVG is only affected due to an implicit width of 100%.

So I guess I'm just asking that if there is a change here, that it won't be overly complicated for this rather special case.

[tabatkins]

Chrome Dev now matches Firefox in this case, which means both match the spec. It's probably not worth trying to do something different at this point, then, so I withdraw the suggestion.