Open Bug 876985 Opened 6 years ago Updated 5 months ago

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

Categories

(Core :: Layout, defect)

defect
Not set

Tracking

()

ASSIGNED
Webcompat Priority ?

People

(Reporter: dholbert, Assigned: dholbert)

References

()

Details

(Whiteboard: [webcompat])

Attachments

(1 file)

Attached file 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.
Assignee: nobody → dholbert
Blocks: css3-flexbox
Status: NEW → ASSIGNED
Component: Layout: Floats → Layout
Flags: in-testsuite?
Summary: flex items with flex-basis:auto and width:auto should get sized with infinite available width → flex items with flex-basis:auto and width:auto should get sized as max-content
Is there any reason for the spec to say it should be max-content?
In my humble opinion, fit-content makes more sense.
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.)
(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.)
(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.
(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.
Flags: webcompat?
Whiteboard: [webcompat]

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

Webcompat Priority: --- → ?

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

You need to log in before you can comment on or make changes to this bug.