- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Jul 2020 20:54:25 +0000
- To: public-css-archive@w3.org
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-sizing-3] Ratio-constrained elements in definite-sized Grid/Flexbox containers == 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](https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes) (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: ```html <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. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5317 using your GitHub account
Received on Monday, 13 July 2020 20:54:27 UTC