Csswg-drafts: [css-flexbox] automatic minimum size: what does min(250, undefined) return?

[davidsgrogan]

<div style="display: flex; width: 100px;">
  <img src="https://placekitten.com/250/250">
</div>

https://jsfiddle.net/dgrogan/seg19ftm/1

What is the used min-width of the img?

The relevant spec text

if the box has an aspect ratio and no specified size, its content-based minimum size is the smaller of its content size suggestion and its transferred size suggestion

says it is min(250, undefined) because the transferred size suggestion is undefined due to its indefinite computed cross size property:

If the item has an intrinsic aspect ratio and its computed cross size property is definite, then the transferred size suggestion is that size (clamped by its min and max cross size properties if they are definite), converted through the aspect ratio. It is otherwise undefined.

So, what is min(250, undefined)? Chrome says 250 and hence the final size of the image is 250x250.

However, in the absence of any guidance, interpreting min(250, undefined) to be 0 would be reasonable. Under such interpretation, the image's final size would be 100x100, which is the size Gecko assigns. (I don't know that this is the reason why though. @dholbert, do you know off the top of your head? If this isn't the reason, any idea why Gecko gives 100x100?)

Should we change some of the "undefined"s in https://drafts.csswg.org/css-flexbox/#min-size-auto to "infinity"? Then min(200, infinity) would be very clear. Or, if Chrome is wrong here, we can s/undefined/0/.

(Apologies if this has been discussed or has a clear definition that I missed.)

/cc @dholbert @fantasai @cbiesinger

[dholbert]

Gecko's behavior here is based on outdated spec text, which said that the automatic minimum width of a flex item is 0 if it has an aspect ratio and no cross-axis constraints.

This will be fixed (hopefully before long) in https://bugzilla.mozilla.org/show_bug.cgi?id=1136312 (yikes, that bug has sat for a long time).

[dholbert]

(In other words, Gecko's not doing a min(250, undefined) sort of operation at all here. We're observing that there are no cross-axis constraints (no specified 'height' or 'min-height'), and we're just resolving the min-width to 0 as a result. This is what the spec used to call for, but doesn't currently.)

[davidsgrogan]

Thanks @dholbert for the explanation of Firefox's behavior.

(The confusion about how to treat undefined here still stands, so I'm leaving this open.)

[davidsgrogan]

Note to self, if this issue resolves such that Chrome's current behavior is wrong, revisit https://crbug.com/625560.

[nightpool]

While I understand that the spec text in this area is probably most correctly interpreted as returning 250, I think that's a really regrettable result, and as an author, I find Firefox's behavior a lot more intuitive and useful then Chrome's in this area.

Ultimately, if I'm using an image (or another sort of replaced element) in a flexbox, it's almost certain that I want a responsive behavior, rather then being too concerned with the original inherent size of the image. Additionally, since flex-shrink is enabled by default, I would expect images to shrink along with other elements, so the use of min-width here seems to me to be inappropriate.

Third, as someone unfamiliar with the spec, the fact that these two documents below render differently is VERY surprising to me, and as an author I would expect a solution that provided consistency in this area:

<div style="display: flex; width: 300px;">
   <!-- These imgs overflow their container -->
  <img src="https://placekitten.com/300/480">
  <img src="https://placekitten.com/300/480">
</div>

<div style="display: flex; width: 300px;">
   <!-- These don't -->
  <div><img src="https://placekitten.com/300/480"></div>
  <div><img src="https://placekitten.com/300/480"></div>
</div>

[fantasai]

The spec's intent was certainly that if any input into the automatic minimum size were undefined, it would be ignored. None of the formulas should ever output the undefined value.

[tabatkins]

@davidsgrogan If one of the inputs doesn't exist, the intention is definitely that it's ignored; it can't contribute to the calculation. We could be more explicit with scattering "(if it exists)" all over the spec, but that seemed like it harmed the readability without adding any real clarity, at least to us at the time. Let us know if you think the spec is unacceptably confusing without that, or if you have better edits to suggest.

@nightpool Both of those examples render identically, with the flex items overflowing the flex container. (Old Firefox (82 or earlier) did render them differently, but exactly opposite to what your comments indicate.) There will be differences if you also set flex: 1; min-width: 0 on the items, but that's a result of the flex items in the first case having an aspect ratio which factors into how their sizes are calculated by the flex model. In the second case the flex items don't have an aspect ratio, only their contents do, so the aspect ratio doesn't factor into the sizing of the flex items. (The images then size into the resulting flex item.)

[davidsgrogan]

Let us know if you think the spec is unacceptably confusing without that

Not unacceptably confusing :)

or if you have better edits to suggest

I think the simplest is what I suggested in the original issue, which is changing "It is otherwise undefined" to "It is otherwise infinity". The definition of min(something, infinity) is very clear (Even in languages like R, where min(4, NA) returns NA and min(4, NaN) returns NaN, min(4, Inf) returns 4.)

But this is no big deal, AFAIK all the engines converged on the behavior you intended (thanks for clarifying!), so this is probably not even worth further discussion, let alone spec edits. Closing.