Re: [csswg-drafts] Implementations don't match the Flex Container Intrinsic Main Sizes algo, resulting in gratuitous differences from equivalent Grid layouts

Ugh, and the specced Flexbox behavior is broken.  It double-applies fractions < 1 when the total sum is < 1. :(((((

To be specific, check [this case](https://jsfiddle.net/Lbvz57zj/) showing off Grid's behavior in a similar case.  Chrome's impl happens to exactly match what the Flexbox says to do (if you translate things back to flex concepts). Note the first box - the max-content size of each item is 200px, so the .4fr calculates to 80px wide, and the .5fr to 100px wide. The grid container is thus 180px wide. Then grid layout happens normally, giving the .4fr column 40% of that space (72px) and the .5fr 50% of the space (90px), making both of them overflow (when only the .4fr one *should* be overflowing; the .5fr should precisely fit its children after linebreaking).  In other words, the fraction gets double-applied.

The fix to this is to check if the sum of flexes is <1, and if so, renormalize the flexes to sum to 1 for the purposes of section 9.9.1.  That will produce a 200px wide container, making the .4fr be 80px wide and the .5fr be 100px wide, exactly as intended; this'll then match the (expected) behavior of the .5/1.0 case, where the .5fr column is 100px wide and the 1.0 column is 200px wide.

(Alternately, do something more complicated in the layout algo to let it know that it's supposed to be snug, and we can ignore the normal behavior of <1 flex and just give it a corresponding share of the total. Both result in the same sizes for the tracks/flex items, but this makes the container smaller and snug around the items.)

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1147#issuecomment-323222618 using your GitHub account

Received on Thursday, 17 August 2017 23:41:09 UTC