User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180809102347 Steps to reproduce: Put a div with overflow: auto inside a flex item. Actual results: The div and flex item both expanded with the content. Expected results: The div should have gotten scroll bars, and the flex item should have retained its size.

This works fine in Chrome (modulo some border/padding calculation differences). The attached test case works as long as overflow is set on the flex item. Removing the overflow gets the undesired behaviour. I don't know if Firefox or Chrome is the one following the spec, but as a web developer I want Chrome's behaviour. Other methods are welcome if this method is not the long term plan. :)

Daniel, do you know if there's a bug tracking something like this? Thanks!

Pierre, are you sure you attached the right testcase? I'm seeing something that feels like what you labeled "Expected results", not "actual results" See attached screencast, where the overflow:auto div gets scrollbars, and where our devtools (at the end of the screencast) show the "content" descendant being 1000px tall but the scrollable div (#scroll) and its flex item parent (#body) are each only 399px tall. I took this screencast in Firefox 61.0.1

(Incidentally, Microsoft Edge matches Firefox's rendering of the attached testcase, too.) There might be a connection to https://bugs.chromium.org/p/chromium/issues/detail?id=581553 here, but it's hard to say until I've got a testcase whose expected/actual results I can reproduce locally. :)

er sorry, mispaste -- I meant to link to these Chromium issues (which may be duplicates of each other, and are blocked on the refactor that I incorrectly linked in comment 4): https://bugs.chromium.org/p/chromium/issues/detail?id=487302 https://bugs.chromium.org/p/chromium/issues/detail?id=596743

Sorry, I was a bit unclear about the test case. As attached, the test case shows the desired behaviour on Firefox. To see the issue disable the "overflow" rule on the #body element. So there are two odd behaviours here: * Why isn't this giving the desired layout without the "overflow"? * Why does the "overflow" property have any effect? It is #scroll that ends up doing the overflow handling, not #body. So the property shouldn't have any effect there. I was thinking it had something to do with block formatting contexts, but #body should already have one as it is a flex item. Other methods of forcing a new block formatting context also don't have any effect.

OK, here's the testcase, with that change.

(In reply to Pierre Ossman from comment #6) > So there are two odd behaviours here: > * Why does the "overflow" property have any effect? It is #scroll that ends > up doing the overflow handling, not #body. So the property shouldn't have > any effect there. This all has to do with the special "min-height:auto" behavior on flex items ("automatic minimum size"): https://drafts.csswg.org/css-flexbox-1/#min-size-auto On flex items with non-default "overflow", there's a special case in the spec that says the min-height:auto resolves to 0, but on all other elements, it resolves to the content height, which in this case is huge. So if #body has a non-default overflow, then it gets a small min-height which doesn't interfere with the layout algorithm. But otherwise (without overflow being set), it gets a large min-height (from its contents) which makes it refuse to be shorter than that huge height. So its child (#scroll) also ends up being super-tall and doesn't get a chance to exercise its own scrollability. Good news: you can get the effect you want more directly by putting "min-height: 0" on the #body element -- that fixes the attached testcase (from comment 7) to give your expected results in Firefox (as well as other browsers). > * Why isn't this giving the desired layout without the "overflow"? The special flexbox "min-height:auto" behavior is making us measure the full content-height of the children, which in this case is pretty huge -- the only piece of explicit content-height that we can measure comes from the #content descendant. So our behavior seems correct to me, per spec (albeit a bit unintuitive). I'm not sure what Chrome's doing or whether there's a bug covering this for them already -- setting needinfo=me to follow up. (Incidentally, it seems Edge matches Chrome on this particular testcase, so that's one other vote against us being correct... There might be some subtlety that I'm not seeing yet.)

(In reply to Daniel Holbert [:dholbert] from comment #8) > On flex items with non-default "overflow", there's a special case in the > spec that says the min-height:auto resolves to 0, but on all other elements, > it resolves to the content height, which in this case is huge. Sorry, I meant to say "on all other _flex items_" (not all other elements). (And it's actually more subtle than this -- e.g. there are special cases for flex items with intrinsic aspect ratios, which may get a "transferred size" from the orthogonal dimension, but those special cases aren't applicable here I think)

Thank you for those pointers to the spec. I agree with your interpretation that Firefox is following the spec. However, I would vote for this getting another round in the standardisation as it is very unintuitive and pretty much impossible to figure out without digging around in the spec. A specified height of a parent element is rarely overridden like this. Are there any discussions available to read to better understand why the normal default of 0 wasn't appropriate here?

(In reply to Pierre Ossman from comment #10) > However, I would vote for this getting another round in the standardisation > as it is very unintuitive and pretty much impossible to figure out without > digging around in the spec. A specified height of a parent element is rarely > overridden like this. This "min-height:auto" special case doesn't typically override the specified height of the parent -- the specified height sets an upper bound for what min-height:auto resolves to. (Maybe that's what's going wrong in Firefox here -- we do have bug 1331692 on a scenario where that fails, and I could see that being the problem here.) > Are there any discussions available to read to better understand why the normal default of 0 wasn't appropriate here? The "min-width/min-height:auto" feature has evolved quite a bit over the years - you can probably find some stuff on it if you go back through https://www.w3.org/Search/Mail/Public/search?type-index=www-style and look for "min-width auto" and/or "min-height auto". Very roughly, though, the idea is as follows: - It's nice for the *default* flex items sizing behavior to produce the max-content size, when space is plentiful -- so that e.g. a default-styled flex item with contents "I am a wide flex item" will get laid out on a single line and will be exactly as wide as it needs to be, in scenarios where there's plenty of space. e.g. in my ASCII art below, where || shows the bounds of the flex container and [] shows the bounds of each flex item. Note that there is excess space in the container here: |[I am a wide flex item][OtherItem] | - HOWEVER, if there's not enough space, it'd be nice to allow wider flex items to gracefully shrink as much as they can without overflowing. e.g. |[I am a wide ][OtherItem]| |[flex item ] | Note that "OtherItem" doesn't shrink at all here, because it can't shrink without overflowing. - To achieve this, the spec editors decided on these defaults: * flex-basis defaults to max-content size (to use all the space we need when space is plentiful) * flex-shrink defaults to 1 (to allow graceful shrinking if there's not enough space) * min-width and min-height default to "auto" now, which (for a flex item) is roughly the min-content size with some other special behaviors. (to set a graceful limit on how much shrinking can occur)