You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the example below, the spec dictates a final width of the flex item of 50px. But when the same element is a block box it has width 100px. Should they be different?
<divstyle="display: flex;"><!-- Chrome and spec say final width is 50px. Firefox says 100px. --><divstyle="background: blue; height: 100px; aspect-ratio: 1/2; "><divstyle="width: 100px;"></div></div></div><!-- Everyone agrees final width is 100px --><divstyle="background: blue; height: 100px; aspect-ratio: 1/2; "><divstyle="width: 100px;"></div></div>
Of course a flex item can have a different final size than an otherwise-identical block box because the whole point of a flex container is that it flexes the items. But this item is not flexed, and it's still a different size. That seems weird.
In more detail, the difference in this case is a result of aspect-ratio's automatic minimum size being more aggressive than flexbox's. Giving flex a weaker set of constraints makes sense, because we want to give flexbox the power to flex its items. But it is puzzlement-inducing that putting a no-op flex container around an element changes the element's size.
Possible solution if we want the boxes to be the same width whether they are block boxes or unflexed flex items (i.e. Firefox's behavior today):
Then we'd also have to change specified size suggestion to only account for computed main size properties, not preferred sizes that come from the aspect-ratio. As is, specified size suggestion is 50px, so even we did (1) and only (1), the final width of the item would still be 50px.
Or, do whatever Firefox is doing, which is probably not those.
But, if giving the blue box different sizes in the two layout modes doesn't strike anyone else as weird, then maybe we just close this issue and discard the idea of making content-size suggestion = min-intrinsic. Even if we do that, we still need to determine which of Firefox and Chrome behavior is correct.
https://drafts.csswg.org/css-flexbox/#min-size-auto
This issue stems from an interop problem discussed in web-platform-tests/wpt@21a7c47 .
In the example below, the spec dictates a final width of the flex item of
50px. But when the same element is a block box it has width100px. Should they be different?https://jsfiddle.net/dgrogan/2734sdfr/
Of course a flex item can have a different final size than an otherwise-identical block box because the whole point of a flex container is that it flexes the items. But this item is not flexed, and it's still a different size. That seems weird.
In more detail, the difference in this case is a result of aspect-ratio's automatic minimum size being more aggressive than flexbox's. Giving flex a weaker set of constraints makes sense, because we want to give flexbox the power to flex its items. But it is puzzlement-inducing that putting a no-op flex container around an element changes the element's size.
Possible solution if we want the boxes to be the same width whether they are block boxes or unflexed flex items (i.e. Firefox's behavior today):
Or, do whatever Firefox is doing, which is probably not those.
But, if giving the blue box different sizes in the two layout modes doesn't strike anyone else as weird, then maybe we just close this issue and discard the idea of making content-size suggestion = min-intrinsic. Even if we do that, we still need to determine which of Firefox and Chrome behavior is correct.
[1] or whatever the name is, vis-a-vis #5305