876985 - flex items with flex-basis:auto and width:auto should get sized as max-content

Status: RESOLVED DUPLICATE of bug 1374540

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

tl;dr: Load attached testcase.

EXPECTED RESULTS: Text shouldn't wrap.
ACTUAL RESULTS: Text wraps.

Opera 12.15 (presto) and Chrome 29.0.1516.3 dev (blink/webkit?) both yield EXPECTED RESULTS.

Nighlty yields ACTUAL RESULTS:
  Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20130528 Firefox/24.0

LONGER VERSION:
When running through Opera's submitted-to-w3c flexbox tests, I ran across one case where I think we're doing the wrong thing:
http://hg.csswg.org/test/raw-file/af50541e57c4/contributors/opera/submitted/css3-flexbox/flexbox_flex-formatting-interop.html
We wrap the xxx's into several lines; opera does not. (and the reference case has no wrapping)

The underlying situation is: suppose we have a flex item inside of a fixed-size horizontal flex container, with auto flex-basis and auto width.  How should we get the item's flex base size? (the resolved flex basis)

Currently, we create a reflow state for the flex item and we give it the container's computed width as its available width, and then we grab its mComputedSize:
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFlexContainerFrame.cpp?rev=91a48bb34e1c&mark=630-632,642-644#627

For an auto-sized flex-item, this ends up effectively sizing it as "fit-content"

However, the spec says we should fall into this final "Otherwise" case:
 # ...lay out the item into the available space
 # using its flex basis in place of its main size
 # and treating ‘auto’ as ‘max-content’. The flex
 # base size is the item's resulting main size.
http://dev.w3.org/csswg/css-flexbox/#flex-base-size

SO: we should be treating flex items with auto width and auto flex-basis as "max-content", but we're not currently.

Comment 1

[Oriol Brufau [:Oriol]]

Is there any reason for the spec to say it should be max-content?
In my humble opinion, fit-content makes more sense.

Comment 2

[Daniel Holbert [:dholbert]]

I agree that "fit-content" makes more sense if there's only 1 flex item.  But in any scenario with more than 1 flex item, it doesn't really make any sense at all.  (It assumes we have the container's full size available to us -- and we don't, if there are multiple items.)

Comment 3

[Daniel Holbert [:dholbert]]

(In contrast, 'max-content' is a nice intrinsic size to fall back on here, which has a reasonable definition regardless of how many other items there are / how much space there is.

Note also that flex items are shrinkable down to their min-content size, by default (via flex-shrink:1 & min-width:auto) -- so even though this "max-content" default sizing seems like it might cause overflow, it probably won't in most cases because stuff can shrink to adapt.)

Comment 4

[Oriol Brufau [:Oriol]]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> It assumes we have the container's full size available to us
> -- and we don't, if there are multiple items.

We don't if it has flex-wrap:nowrap, but otherwise why not?

Similarly, inline-blocks don't have the container's full size available to them if it has white-space:nowrap, but that didn't prevent sizing them using fit-content.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Oriol from comment #4)
> We don't if it has flex-wrap:nowrap

(which is the default setting)

> Similarly, inline-blocks don't have the container's full size available to
> them if it has white-space:nowrap,

white-space:nowrap is a non-default setting.  That's a key difference.

It makes sense to design default sizing behaviors with the default scenario (rather than non-default scenarios) in mind as the main usecase where things should make sense.

Anyway, if you really think this should change (or you're still wondering about the justification for the specced behavior), probably better to post to www-style than to have a further back and forth on this bug.

Comment 6

[yisibl]

See also: https://github.com/w3c/csswg-drafts/issues/1290

Comment 7

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 8

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 9

[Leon Sorokin]

the attached test case does not wrap for me in 72.0.2

Comment 10

[Daniel Holbert [:dholbert]]

Thanks, Leon! You're right, I see the same outcome (matching expected results from comment 0).

mozregression --find-fix says this was fixed in this range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6547c27303bc4d8961b11e656751e839807d65c7&tochange=37b8862d354e0014a72715462dd2102dd5b599cc
...which means this fixed by bug 1374540. Resolving as a duplicate of that bug.

Comment 11

[Daniel Holbert [:dholbert]]

(And it looks like the testcases on that bug do include scenarios like "testcase 1" here --> resolving in-testsuite to "+".)