1108514 - A flex-basis: auto; flexbox child expands wider that its flexbox container

Status: RESOLVED DUPLICATE of bug 1086218

(Core :: CSS Parsing and Computation, defect)

Description

[munter]

Attachment: flexbox-firefox-v34.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36

Steps to reproduce:

Create a flex container with flex-direction: row. First child of this container has flex: 0 0 200px;, the other has flex: 1 1; meaning it should expand to fill the rest of the width.

Inside the expanding container there is a child with a width larger than the width the container can expand to.


Actual results:

Firefox 34 has the flex: 1 1; container expand to fit the width of the child


Expected results:

The flex: 1 1; container should not become wider than its flexbox parent allows.

This is a regression from Friefox v33

Comment 1

[munter]

Attachment: Screenshot of bug in effect

This is what the bug looks like

Comment 2

[Daniel Holbert [:dholbert]]

We're matching the spec; chrome is not.  See bug 1086218 comment 4, and bug 1043520.  tl;dr: set "min-width:0" on flex items, if you want them to be shrinkable below their intrinsic width (which they derive from their contents).

I filed http://code.google.com/p/chromium/issues/detail?id=426898 on fixing this in Chrome a while back; I'm hopeful that they'll come into spec conformance soon on this.

Comment 3

[Kohei Yoshino [:kohei]]

Looks like I have already documented this in the 34 compat doc:
https://developer.mozilla.org/en-US/Firefox/Releases/34/Site_Compatibility#CSS

Comment 4

[munter]

I must say that this behavior is highly unintuitive, taking all the existing documentation and tutorials into account. None of them ever show a flex child being able to escape outside a flex container.
And the fix, setting min-width on something that is to wide, is also something that doesn't come natural.

I understand that you are following the spec, and I can appreciate that. In this case I think the spec needs revision.

Comment 5

[Daniel Holbert [:dholbert]]

The spec was *already* revised on this, to remove this feature (& I removed it, in bug 848539) and then re-revised to add it back with tweaks because it was determined to be needed (I added it back in bug 984711, and I implemented the tweaks in bug 1015474).

I strongly doubt it will be re-re-revised to remove it again.

As I recall, the reason "min-width:auto" exists is the following:

 (0) General principle: flexbox should *default* to avoiding overflow / clipped content, for best results (and to behave gracefully in scenarios that web developers don't anticipate).

 (1) To that end: it's useful for "flex-shrink" to default to something nonzero, so that if authors design their pages with flexbox and don't consider small devices, then their flex items will be able to to shrink (where shrinking is possible) by default, instead of overflowing. Hence, flex-shrink defaults to "1", not "0", so that flex items will shrink if necessary.

 (2) BUT, we can't default to letting things shrink to be *zero-sized* -- that would also cause overflow/truncated content, violating the principle that we're trying to achieve with (1). Essentially, we want to allow flex items to shrink until their children start overflowing, and then not shrink any further (by default).

 (3) So, to achieve this:
   - flex items have a flex-shrink of 1 (so they'll shrink by default, to avoid overflowing their flex container)
   - flex items have a special min-width (or min-height) value that prevents them from shrinking below their min-content size (which would likely cause *their contents* to overflow)
   - web developers can disable any of these defaults by setting flex-shrink and/or "min-width" (min-height) directly

Comment 6

[Daniel Holbert [:dholbert]]

In the case of your example, a few observations:
 - The flex item in question is auto-sized, to fit its content. (i.e. it has "flex-basis:auto; width:auto").  So it  *starts out* at 600px -- too wide for the container.
 - The only reason it fits (in Chrome) is because of the default "flex-shrink:1" *making it shrink* below its default width.
 - In Firefox (and per the spec), it is *not supposed* to shrink like that -- not below its min-content width -- because shrinking beyond that point will mean that the flex item's content will potentially overflow outside of the flex item. (In your case, it doesn't overflow, because the wide stuff is inside of an "overflow:auto" element.)
 - If the flex item *itself* were "overflow:auto", then (per spec) we'd detect that overflow won't be problematic and we'd make "min-width:auto" resolve to 0. However, in your case it's another element that's "overflow:auto". This produces unintuitive results, but no one's come up with a concrete proposal that addresses this, and it's late-in-the-game enough that I doubt the spec will be changed to handle this at this point.

[Only posting these comments to provide context for the "the spec needs revision" comment in comment 4. It's complicated, unfortunately. :-/ ]

Comment 7

[munter]

Thanks for clearing things up. I know I'm way to late for changes to be made. Not an early enough adopter I guess.

This is a pretty good resource for figuring out what's going on now though :)