Closed Bug 1114904 Opened 10 years ago Closed 10 years ago

Nested flexbox does not shrink overflowing content with overflow:auto

Categories

(Core :: Layout, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: orivej, Unassigned)

References

()

Details

Attachments

(3 files)

Attached file test.html (deleted) —
The attached test.html used to display the inner content contained on a page (see good.png) prior to Firefox 34. Since Firefox 34, and specifically since the changeset 195506:b2c96bbed41d, the inner content overflows horizontally (see bad.png). I don't know how it should look according to the spec, but the old rendering is needed for page layout with flexbox. Chrome 39 renders the test like good.png, and Opera 12 like bad.png.
Attached image good.png (deleted) —
Attached image bad.png (deleted) —
The behavior you see in Firefox 34 is following the current spec. Chrome 39 is implementing an old spec version. If you want the old behavior, you want to style your <div class="inner"> with "min-width: 0" instead of the default "min-width: auto".
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Thank you for the practical solution and for the link to the tracking bug. I've read the relevant part of the spec (http://dev.w3.org/csswg/css-flexbox/#min-size-auto) and the proposal (http://lists.w3.org/Archives/Public/www-style/2013Jul/0456.html), and it seems that Firefox violates the current spec. When reintroducing min-width/height:auto, the authors of the spec wanted sensible behaviour for scrolling flex children and stated it thus: if (overflow != visible): min-width/height = 0; else min-width/height = min(min-content, width/height); In the test.html ‘overflow’ is not ‘visible’, so I shouldn't have to specify min-width/height by myself.
That chunk of the spec is talking about *flex items*. (Flex items = direct children of a flexbox.) In your testcase, "overflow:auto" is not on a flex item -- it's on a *child* of a flex item. (Your <div class=outer> is display:flex, which makes <div class=inner> a flex item -- and you have "overflow:auto" set on <pre>. If you set it on <div class=inner> instead of on <pre>, you'll see that we do the right thing -- we are following the spec on this point. You're not alone -- this seems to be the exact problem most of the time, when web developers run into this. I mentioned this on bug 1043520 comment 6 and emailed the CSSWG about it here: http://lists.w3.org/Archives/Public/www-style/2014Jul/0589.html It seems there's not much that can be done, besides educating web developers about the quirky min-sizing behavior and "min-width:0"/"min-height:0")
Daniel, I would have accepted your explanation if my <pre> was not a flex item, but it is, since <div class=inner> is not only a flex item of <div class=outer>, but a flex container in its own right. If <pre> is a flex item with "overflow:auto", its min-width must compute to 0 and should stretch neither of its parent <div>s.
Ah, you're right -- thanks for the polite clarification, & sorry for missing that important detail. That doesn't change the fact that .inner *itself* is still sized with "min-width: min-content", though -- because *it* is a flex item, and it has min-width:auto". So while .outer is doing its own flex layout, it prevents .inner from shrinking below its min-content size (which happens to be huge). Independently: when .inner is layout out *its* contents, its child's "min-width:auto" resolves to 0, per the spec-text that you quoted. This doesn't change .inner's own min-content width though (as reported to its parent, .outer) -- and .outer makes sure that .inner doesn't dip below its min-content width. (It intuitively seems like "overflow:auto" should influence the min-content width of an element & its ancestors, but it does not.)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: