[csswg-drafts] Flexbox's "Flex Container Intrinsic Main Sizes" algo is gratuitously different from the equivalent Grid algo

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== Flexbox's "Flex Container Intrinsic Main Sizes" algo is gratuitously different from the equivalent Grid algo ==
Quoting myself from #1120:

> The different between Grid and Flexbox here is in how we calculate the size of the container when some of the items have <1 flexibility, and the available space is indefinite (such as in a float).
>
> Specifically, Grid's behavior is defined in https://drafts.csswg.org/css-grid/#algo-flex-tracks, the "If the free space is an indefinite length" substep. In your examples, it ends up computing a "used flex fraction" of 100px. In the .5/1 example, then, the tracks get sized to 50px/100px, respectively, and the grid then shrinkwraps those two tracks, being 150px wide total.
>
> In Flexbox, the behavior is defined in https://drafts.csswg.org/css-flexbox/#intrinsic-sizes, where the "max content flex fraction"s end up computing to 0, and each item has a flex base size of 100px (due to its contents), so the flex container's size is the sum of (FBS + MCFF) for each item, or 200px wide total. If there's a .5/1 flex on the children, the sum of flexes is >1, so they then distribute that 200px with a 1:2 ratio, making the items approximately 67px/133px wide. (If the sum is <1, they get sized to an appropriate fraction of the 200px, leaving some empty space in the flexbox. The container does maintain its 200px width regardless, tho.)
> 
> I'm pretty sure Flexbox is the one with the bad behavior here. The container should pay attention to <1 flex values when finding its size, like Grid does. I'll file a bug for Flexbox instead.

Testcase showing off the differences: <https://jsfiddle.net/7L9j7qjw/>

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1147 using your GitHub account

Received on Thursday, 30 March 2017 19:13:46 UTC