[css-flexbox] Change content-size suggestion to min-intrinsic instead of min-content?

[davidsgrogan]

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):

1. 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))
2. 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

[davidsgrogan]

Looks like Gecko does something like

content-size suggestion = max(min-content, min-intrinsic)

or maybe Gecko floors the entire automatic minimum size?

min-size:auto = max(min-size:auto, min-intrinsic)

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]

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.

max(blue background div's height 100px * (1/2), blue background's child width 100px) = 100px

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]

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]

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]

The underlying behavior difference may explain why firefox and chrome have different renderings for the example below.

<div style="display: flex; flex-direction: column; height: 0px;">
  <div style="aspect-ratio: 1/1; width: 100px; border: 5px solid orange;">
    <div style="height: 200%; background: blue;"></div>
  </div>
</div>

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]

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]

@tabatkins and I think some of the confusion here comes from missing a small nuance in this paragraph:

The content-based minimum size of a flex item is the smaller of its specified size suggestion and its content size suggestion if its specified size suggestion exists; otherwise, the smaller of its transferred size suggestion and its content size suggestion if the element is replaced and its transferred size suggestion exists; otherwise its content size suggestion.

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

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.

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:

diff --git a/css-flexbox-1/Overview.bs b/css-flexbox-1/Overview.bs
index 2c3418beb..358740409 100644
--- a/css-flexbox-1/Overview.bs
+++ b/css-flexbox-1/Overview.bs
@@ -1001,7 +1001,7 @@ Grid doesn't have similarly meaningful shrinkability, so it doesn't need to care
 	<dl>
 		<dt><dfn>specified size suggestion</dfn>
 		<dd>
-			If the item’s [=preferred size|preferred=] [=main size=] is <a>definite</a>,
+			If the item’s [=preferred size|preferred=] [=main size=] is <a>definite</a> and not [=automatic size|automatic=],
 			then the <a>specified size suggestion</a> is that size.
 			It is otherwise undefined.

Committed in ca4dc9e .

[tabatkins]

In #6794 (comment),
@Dgrogan brought up the following example:

<div style="display: flex; flex-direction: column; height: 0px;">
  <div style="aspect-ratio: 1/1; width: 100px; border: 5px solid orange;">
    <div style="height: 200%; background: blue;"></div>
  </div>
</div>

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]

Propose to close as editorial / invalid. Please let us know if we need to consider anything else!

[davidsgrogan]

Could you explicitly say which engine, if any, renders the original case correctly?

<div style="display: flex;">
  <!-- Chrome says final width is 50px. Firefox says 100px. -->
  <div style="background: blue; height: 100px; aspect-ratio: 1/2; ">
    <div style="width: 100px;"></div>
  </div>
</div>

[fantasai]

@davidsgrogan

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.

— #6794 (comment)

Unless there's something we missed?

[dholbert]

@tabatkins , one thing I'm confused about in your analysis -- you say:

So the flex base size is 100px (from the transferred width), and the automatic minimum size is zero

Why do you say the automatic minimum size is zero -- shouldn't it actually be 100px?

The flex item here should use the content-size suggestion i.e. its min-content height, per https://drafts.csswg.org/css-flexbox-1/#min-size-auto (since it doesn't have a specified size suggestion and is not replaced).

And I think its min-content height is 100px, not 0. At least, this simplified example (with just a single div that has explicit height:min-content) suggests that it is:

<!DOCTYPE html>
<div style="aspect-ratio: 1/1;
            width: 100px; height: min-content;
            background: blue; border: 5px solid orange">
</div>

Browsers agree that this^ div is 100px tall, which I think (?) means its height:min-content is resolving to 100px and hence that's its min-content height? So I'd think that that's what the content size suggestion should be, when resolving its automatic minimum size in Tab's analysis above.

[dholbert]

For completeness, I'll point out that browsers also agree that the div in the other example here (the row-oriented flex container that @davidsgrogan asked about) does indeed have a 100px min-content width which (as fantasai noted) agrees with Firefox's behavior in that case. Here's a simplified example with width:min-content to demonstrate that the min-content width is indeed 100px there:

<div style="aspect-ratio: 1/2;
            height: 100px; width: min-content;
            background: blue; border: 5px solid orange">
  <div style="width: 100px;"></div>
</div>

In this^ case, the min-content width does actually come from its content, i.e. its 100px-wide child; but if you edit the example to remove that child, then browsers also agree that the div ends up being 50px wide there instead (from the aspect-ratio and cross-axis size).

So, this seems to be further confirmation that the min-content size is indeed established by the aspect-ratio and the opposite-axis property (though it might be bigger the element contains content that is even larger).

[bfgeek]

@dholbert - That example is using the min-width: auto to size up to 100px, its not strictly that "min-content" is 100px in this case. E.g.

<div style="aspect-ratio: 1/2;
            height: 100px; width: min-content; min-width: 0;
            background: blue; border: 5px solid orange">
  <div style="width: 100px;"></div>
</div>

In the above case all browsers agree that its 50px.
Here min-content is 50px, but with min-width: auto, we apply a minimum of the intrinsic min-size of 100px.

[dholbert]

@bfgeek aha, thank you for clarifying that. I had forgotten that aspect-ratio had its own special min-width:auto behavior even with no flex/grid involvement.

OK - with that clarification, I think @tabatkins' and @fantasai's notes above make sense to me. EDIT: still confused, see my next comment.

[bfgeek]

@dholbert - Given that clarification I think there is still a terminology issue here. E.g.

<div style="display: flex;">
  <!-- Chrome says final width is 50px. Firefox says 100px. -->
  <div style="background: blue; height: 100px; aspect-ratio: 1/2; ">
    <div style="width: 100px;"></div>
  </div>
</div>

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.

In the given example (afaikt) the min-content size (given that it has an aspect-ratio) is actually 50px not 100px.

One thing that might mitigate the confusion here is to change the definition of min-content such that when we compute it we look to see if min-width: auto is present.

Ian

[dholbert]

[retracting my "things make sense" comment]

So per @bfgeek 's example and comments, it sounds like the min-content size of an element with aspect-ratio and an opposite-axis size is defined by the aspect-ratio and the specified-size in the opposite axis (which corrects my misunderstanding in #6794 (comment) ).

So, my confusion from #6794 (comment) remains -- I'm not sure I agree with @tabatkins that the automatic minimum height of the flex item would be zero in Tab's analysis in #6794 (comment) . I would think it should be the min-content size, which (per bfgeek's notes about how width:min-content resolves) would be determined by the aspect-ratio and the opposite-axis size.

[tabatkins]

Why do you say the automatic minimum size is zero -- shouldn't it actually be 100px?

Mea culpa, you're right. When writing that down, I tripped over the fact that (a) the blue child resolves to 0 height while calculating the automatic minimum size, and (b) the specified size suggestion shouldn't take aspect-ratio into account (we had just dropped a minor edit into there to make sure that automatic sizes couldn't contribute even if they're definite), and so forgot to think about aspect-ratio when talking about the content size suggestion, which should take that into account. You're correct that the automatic minimum size in this case is 100px.

So neither Chrome nor Firefox is quite right here. Instead, the orange item starts at 100px flex basis, isn't allowed to shrink below 100px, and the blue child then resolves its % against that, resulting in the blue box being 200px tall.

[davidsgrogan]

@davidsgrogan

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.

— #6794 (comment)

Unless there's something we missed?

Sorry, I totally missed that paragraph.

But the content size suggestion is not 100px, it's 50px (as mentioned in #6794 (comment)).

My point from #6794 (comment) still stands. Slightly reworded:

https://drafts.csswg.org/css-flexbox-1/#min-size-auto gives a definition of automatic minimum sizing for flex items.
https://drafts.csswg.org/css-sizing-4/#aspect-ratio-minimum gives a definition of automatic minimum sizing for aspect-ratio elements.
As seen in this case, those definitions don't always agree.

So what do we do in the case of a flex item with an aspect ratio? Which minimum do we apply?

These definitions need to be modified so that they always agree (which I think is what Ian proposes in the last sentence of #6794 (comment)) OR if they don't agree, we need explicit instruction of which to honor (which is possibly both).

[tabatkins]

@bfgeek

In the given example (afaikt) the min-content size (given that it has an aspect-ratio) is actually 50px not 100px.

Where are you getting that from? Are you assuming this is from the aspect-ratio affecting the specified size suggestion? We made a small tweak to prevent that, specifying it only looks at non-automatic definite sizes, specifically because it was creating an unintentional conflict with the aspect-ratio auto minimum size. (And was pre-empting the other size suggestions which were intended to handle aspect ratios.) (And it was just wrong anyway, as it would made made width: auto provide a specified size suggestion even without aspect ratio, which would have been all kinds of wrong.)

[tabatkins]

OR if they don't agree, we need explicit instruction of which to honor (which is possibly both).

Yeah, we should make it clear what to do when they disagree. I suspect we want to honor the larger of the two (aka both minimums are active).

[bfgeek]

Where are you getting that from? Are you assuming this is from the aspect-ratio affecting the specified size suggestion?

I'm describing how engines derive the min-content size of a non-replaced element with an aspect-ratio - (which feeds into the content suggestion for this specific example). E.g. for this case this rectangle has a min-content size of 50px :

<div style="aspect-ratio: 1/2;
            height: 100px; width: min-content; min-width: 0;
            background: blue; border: 5px solid orange">
  <div style="width: 100px;"></div>
</div>

The min-content size itself doesn't apply any automatic minimum sizing. (We don't read min-width when computing the min-content size). One option here is that it can! This would solve the issue.

Given that above is 50px we feed this into the content size suggestion which gives Chrome's output for the flexbox example being talked about.

[aethanyc]

Yeah, we should make it clear what to do when they disagree. I suspect we want to honor the larger of the two (aka both minimums are active).

#5268 is the related question whether aspect-ratio's automatic minimum size should be applied in both axes or just in the block axis.

[bfgeek]

@mirisuzanne Were you able to compile any thoughts here?

[mirisuzanne]

I'm not sure I have anything new to provide here. I'm not a big fan of the default flex values, but that ship has long sailed. I'm also not fully-versed in all the intricacies and magics involved with the different sizing algorithms discussed - which makes it hard to comment on the difference between min-width of auto vs min-content. By default, I would reach for the latter - but I do not fully understand the implications of that, and would want someone to walk me through those examples more explicitly.

At the higher level of my author expectations:

• I do think it's fair to say that authors prioritize aspect-ratios in many/most situations where they are set. When you want an aspect ratio, there's usually a reason for it, and things often start to break when those aspect-ratios are discarded.
• Flexible items with aspect ratios always have problems at their extremes, and almost always need guard-rails defined – either with min/max-widths, or queries to change the layout more dramatically. There's no one-size-fits-all answer.
• In general, I would expect flex items that shrink or grow to handle their aspect-ratios in the same way.

When using aspect-ratio with flexbox, I would almost never set an explicit size on the cross-axis. The whole point would be maintaining a ratio as the item flexes. The only reason I can imagine ending up in this situation is if I'm using flexbox to lay out non-flexible items. Either way, I would want to clarify:

• If I want the items to flex, there shouldn't be an explicit height-and-ratio, I should choose one or the other. In that case, I probably also need guard-rails at the extremes.
• If I don't want items to flex, the height makes some sense - but then I should turn off flex-shrink.

Of course we need a default here, but I don't see a 'right' one. Both defaults look broken, because this is not a clear use-case - and I would want to provide a fix either way. Like I said in the call: what's important to me is that I have good options for clarifying my intent in either direction once this breaks.

It would be a lot easier to comment here if any of the examples were based in actual use-cases.

[bfgeek]

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]

<!DOCTYPE html>
Both these should render the same
<div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column">
	<div style="aspect-ratio: 1; background-color: red;"></div>
	<div style="min-height: 100px; background-color: blue;"></div>
</div>
<div style="width: 100px; height: 100px; display: inline-flex; flex-direction: column">
	<div style="width: 100%; aspect-ratio: 1; background-color: red;"></div>
	<div style="min-height: 100px; background-color: blue;"></div>
</div>

(in the row direction https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12477 which only Blink is consistent).

[bfgeek]

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]

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 size

The 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