Skip to content

Implementations don't match the Flex Container Intrinsic Main Sizes algo, resulting in gratuitous differences from equivalent Grid layouts #1147

Closed
@tabatkins

Description

@tabatkins

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/

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions