Repository navigation
[css-flexbox] Change content-size suggestion to min-intrinsic instead of min-content? #6794
Description
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 width 100px. Should they be different?
<div style="display: flex;">
<!-- Chrome and spec say final width is 50px. Firefox says 100px. -->
<div style="background: blue; height: 100px; aspect-ratio: 1/2; ">
<div style="width: 100px;"></div>
</div>
</div>
<!-- Everyone agrees final width is 100px -->
<div style="background: blue; height: 100px; aspect-ratio: 1/2; ">
<div style="width: 100px;"></div>
</div>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):
- change content-size suggestion to be min-intrinsic[1] instead of min-content (@bfgeek previously floated this idea In [css-sizing-4] Should aspect-ratio affect the intrinsic size? #5032 (comment))
- 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.
[1] or whatever the name is, vis-a-vis #5305
Activity
Compute transferred size suggestion only if a flex item is a replaced…
davidsgrogan commentedon Nov 10, 2021
Looks like Gecko does something like
or maybe Gecko floors the entire automatic minimum size?
Seems reasonable and Blink can try to match if that's the behavior we end up adopting.
@dholbert @aethanyc , can you report what logic Gecko follows such that the flex item in https://jsfiddle.net/dgrogan/2734sdfr/ has automatic minimum width of 100px?
aethanyc commentedon Nov 10, 2021
For the flex item in https://jsfiddle.net/dgrogan/2734sdfr/, Firefox only has content size suggestion, which follows the same logic described in https://drafts.csswg.org/css-sizing-4/#aspect-ratio-minimum, i.e.
Firefox currently only applies specified size suggestion only if there's a main size property. However, the current spec implies that the specified size suggestion is the item’s preferred main size, which can be computed via aspect-ratio + definite cross-size. @dholbert pointed to me that the definition was changed after the edit in 0c1a35d, and this seems changing the behavior.
davidsgrogan commentedon Nov 11, 2021
Oh, y'all apply aspect-ratio's automatic minimum size on top of flex's. Maybe Blink should match.
Blink matches Gecko about when to apply specified side suggestion.
davidsgrogan commentedon Dec 23, 2021
https://drafts.csswg.org/css-flexbox-1/#min-size-auto gives one definition of automatic minimum sizing. https://drafts.csswg.org/css-sizing-4/#aspect-ratio-minimum gives another. They don't always agree.
@tabatkins @fantasai , what do we do in the case of a flex item with an aspect ratio? Apply both minimums?
Chrome only applies flexbox's. I think Firefox applies both.
davidsgrogan commentedon Jan 5, 2022
The underlying behavior difference may explain why firefox and chrome have different renderings for the example below.
Chrome 99 canary gives 0 height to both orange item and blue child.
Firefox 95a1 gives 200px height to orange item and 400px height to blue child.
css-meeting-bot commentedon Jan 26, 2022
The CSS Working Group just discussed
[css-flexbox] Change content-size suggestion to min-intrinsic instead of min-content?.The full IRC log of that discussion
<emeyer> Topic: [css-flexbox] Change content-size suggestion to min-intrinsic instead of min-content?<emeyer> github: https://github.com//issues/6794
<emeyer> fantasai: I think I need to go back to read the flexbox specs from the very beginning to figure out what I think should happen here.
<emeyer> …I think we have to decide what behavior we want here and how to achieve that.
<emeyer> …I’m not sure I’m clear on any of that.
<emeyer> TabAtkins: Same here. This is important and VERY difficult to reason about correctly, and we need more time.
<emeyer> dgrogan: Base issue is that aspect-ratio define sizing one way and flex defines it another
<emeyer> …and they conflict when you aspect-ratio a flex item.
<emeyer> TabAtkins: That’s what I understand. I don’t know how to resolve that yet.
<emeyer> dgrogan: Before we start talking about changing the spec, should I change Chrome to match Firefox where they apply both minimums?
<emeyer> TabAtkins: Wouldn’t that answer the question?
<emeyer> …Because if you change to match Firefox, then the spec will just match whetever you do.
<emeyer> dgrogan: Okay, let’s pinch this off now.
<emeyer> astearns: Will remove Agenda+ and will put it back once fantasai and tabatkins have time.
<emeyer> iank_: Can we do this quickly? It’s a major problem.
<emeyer> TabAtkins: That’s the goal.
<emeyer> astearns: Let’s wait on this for now.
fantasai commentedon Jan 31, 2022
@tabatkins and I think some of the confusion here comes from missing a small nuance in this paragraph:
The flex item in question does not have a specified size suggestion, and is not replaced, and therefore it falls through to the final clause and uses its content size suggestion which is its min-content size in the main axis (100px). Therefore Firefox's behavior here is correct.
@aethanyc mentioned
0c1a35d was definitely not meant to change behavior, but I can see how switching the emphasis from the “computed value” would change how automatic sizes are interpreted. We need to clarify that we're only considering non-automatic definite sizes:
Committed in ca4dc9e .
tabatkins commentedon Jan 31, 2022
In #6794 (comment),
@Dgrogan brought up the following example:
Chrome's behavior here is correct. The min-content contribution of the blue box is zero due to the cyclic percentage size rules in https://www.w3.org/TR/css-sizing-3/#cyclic-percentage-contribution. So the flex base size is 100px (from the transferred width), and the automatic minimum size is zero, resulting in a 100px hypothetical main size.
Then, since the flex container is 0px tall and the item is flexible, it shrinks down to its minimum size (0px). The blue box's percentage then resolves against that zero during layout, so the blue box is also zero.
Firefox renders this with a 200px tall orange box, and a 400px tall blue box, which means in their implementation the percentage is looping and self-applying, and just happens to be cut off on two applications. This is because they are not applying the cyclic percentage rules
while calculating the orange box's automatic minimum height: they are allowing the blue box's percentage
to resolve against the orange box's 100px automatic height, resulting in the orange box getting an automatic minimum height of 200px. The orange box then can't shrink below that, so during layout the blue box resolves its percentage against the 200px height, giving it a final height of 400px.
fantasai commentedon Jan 31, 2022
Propose to close as editorial / invalid. Please let us know if we need to consider anything else!
72 remaining items
bfgeek commentedon Mar 20, 2024
As a data-point, we a starting to receive some bug reports about out behaviour (specifically for this case: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12476 [1] )
With people expecting WebKit's behaviour.
[1]
(in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent).
bfgeek commentedon May 17, 2024
As another data-point, we've received another web developer bug report about our current (min-intrinsic) behaviour being perceived as incorrect while the min-content behaviour perceived as correct. It's more or less this case:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12739
Agenda+ to move to the min-content behaviour.
css-meeting-bot commentedon May 22, 2024
The CSS Working Group just discussed
[css-flexbox] Change content-size suggestion to min-intrinsic instead of min-content?, and agreed to the following:RESOLVED: change minimum size of flex items to be the larger of min-intrinsic and transferred sizeThe full IRC log of that discussion
<emilio> iank_: this is re auto min size on flex items and aspect-ratio<emilio> ... blink is more or less consistently dropping the aspect-ratio
<emilio> ... other browsers are sometimes dropping it
<emilio> ... blink has been on the receiving end of a bunch of web dev bug reports
<emilio> ... this situation isn't good for web devs
<emilio> ... haven't seem bug reports for the other engines
<emilio> ... as such I think we would do a change to respect aspect-ratio
<emilio> ... we can add a bunch of tentative tests about this behavior
<emilio> ... proposal would be max(aspect-ratio, min-intrinsic size)
<TabAtkins> I'm happy to take the change, I'll just have to spend some time digesting exactly what it is. But if we're getting compat issues and webdevs are preferring one behavior, let's do it.
<dholbert> s/aspect-ratio/transferred-size/
<dholbert> (in the min() expression)
<dholbert> (er max() expression)
<emilio> fantasai: I'd like to
<fantasai> s/I'd like to/I'm the same as Tab here/
<emilio> ... TabAtkins and I would like to spend some time on this issue, but if there are compat issues...
<emilio> iank_: Yeah I'm going to try changing blink and add tests
<emilio> fantasai: I think I understand the proposal now
<emilio> ... I think it makes sense?
<chrishtr> +1 to accepting the change
<emilio> astearns: should we resolve on accepting this change tentatively?
<emilio> q+
<astearns> ack emilio
<emilio> iank_: what's going on is web devs really hate it when the aspect-ratio gets dropped
<emilio> q+
<emilio> iank_: I think proposed resolution would be to change the AMS of flex items to be max(min-intrinsic-size, transferred-size via aspect-ratio)
<astearns> ack emilio
<fantasai> fantasai: ok, got it
<fantasai> emilio: Do we understand what Gecko and WebKit are doing?
<fantasai> iank_: I understand, it's complicated
<fantasai> iank_: WebKit and Gecko are inconsistent between row/column axes, and aren't consistent in when transferred size is applied.
<emilio> they are inconsistent between column / row and how the transferred size is getting applied
<fantasai> iank_: everyone is super inconsistent
<fantasai> emilio: if you could write it up, I'd be curious
<fantasai> iank_: my intention was to write out a suite of testcases for this behavior
<fantasai> iank_: that should show what's happening
<fantasai> iank_: issue is that Web devs are running into behavior where WEbkit/Gecko are consistent in honoring aspect ratio and Blink isn't
<fantasai> emilio: so your proposal would be breaking changes for all three engines
<fantasai> emilio: right?
<fantasai> iank_: yes, because we're all inconsistent. And inconsistent across axes. Basically everyone is bad.
<fantasai> iank_: we're probalby the most consistent, but not what web devs expect
<fantasai> iank_: so that's where we are
<fantasai> emilio: ok, this sounds good. We'll look at tests. On paper sounds reasonable.
<fantasai> iank_: given lack of bug reports on other engines, not worried
<fantasai> astearns: Proposed resolution to change minimum size of flex to be the larger of min-intrinsic and transferred size
<emilio> PROPOSED: change the AMS of flex items to be max(min-intrinsic-size, transferred-size via aspect-ratio)
<emilio> RESOLVED: change minimum size of flex items to be the larger of min-intrinsic and transferred size
[css-flexbox-1] Make non-replaced elements consult the transferred si…
[css-flexbox-1] Make non-replaced elements consult the transferred si…
fantasai commentedon Jun 29, 2025
Fixed in #11690
Cherry-pick eaf5e54. rdar://problem/101346126
Bug 1793024 [wpt PR 36113] - [css-flex] Change expectations of two as…