- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Mar 2017 19:00:54 +0000
- To: public-css-archive@w3.org
Interesting! Javi's right that "sum less than 1" isn't quite the issue. 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. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1120#issuecomment-290511716 using your GitHub account
Received on Thursday, 30 March 2017 19:01:00 UTC