marko Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
Firefox for Android

Steps to reproduce:

Overflox in flexbox containers and display:flex elements does not work as expected. Please see the attached CodePen http://codepen.io/anon/pen/MYNJpG


Actual results:

IE 11 and Chrome (latest) both render overflow-y scrollbars as expected, Firefox does not. Please see the attached CodePen http://codepen.io/anon/pen/MYNJpG


Expected results:

Since the height is limited, scrollbars should be shown for overflowed content.

The same issue exists in Firefox for Android.

	Daniel Holbert [:dholbert]
	Comment 1 • 9 years ago

This is a result of "min-height:auto" behavior, which Firefox is the only shipping browser to implement. (Though Chrome implemented it in their development tip yesterday, according to
   https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/44yUDgkjWXU


You need to add "min-height:0" to your 'main' element, to allow it to be smaller than its contents' intrinsic height (and allow its contents to exercise their own overflow properties). Updated codepen, with that change:
  http://codepen.io/anon/pen/VYoBNa

	Daniel Holbert [:dholbert]
	Comment 2 • 9 years ago

See my answer here for more details:
http://stackoverflow.com/questions/26895349/how-can-i-get-ff-33-x-flexbox-behavior-in-ff-34-x/26916542#26916542

Flexbox spec text on this:
 http://dev.w3.org/csswg/css-flexbox/#min-size-auto

	marko Reporter
	Comment 3 • 9 years ago

Hey Daniel, thank you for the response. It solves a lot of my other problems with overflow too.

However, I have to admit this spec doesn't make any sense. 

If one has to add something as obscure as min-height: 0 to their CSS to achieve the behavior that makes the most sense (and something that behaves as everything else behaved so far when it comes to overflows) then it is very likely that the spec is wrong.

	Daniel Holbert [:dholbert]
	Comment 4 • 9 years ago

I'll give you a quick example of why the specced behavior makes some sense -- though please don't take this as an invitation to debate the merits of the spec. :) If you think the spec should change, you'd want to contact the CSSWG, not post on a particular browser-vendor's bugzilla. (Though it's extremely unlikely that this would change at this stage of the game)

Anyway -- at a high level, min-width:auto makes simple scenarios behave nicely, with minimal CSS, without risking clipped/overflowing content unless absolutely necessary.  The cost of this is that some complex scenarios (like your scenario, with 'overflow' set on the child of a flex item) become a bit counterintuitive and require a "min-width:0" or "min-height:0" hack to do what you really want.

Here's one example which demonstrates the benefit of "min-width:auto": two buttons, which the author wants to have the same width, but also probably doesn't want their contents to overflow. All you need is "flex:1" on each button, and it Just Works without anything overflowing, unless absolutely necessary.

Demo: https://jsfiddle.net/xwbhn1tm/3/

Basically: when there's enough space, the two buttons will each get 50% of the container's space. (This is the idea behind "flex:1") BUT, when space is constrained (which could happen in the wild, without the author necessarily predicting it, due to the user picking a different font-size or viewing the page on a small screen or resizing their browser), then dividing up the space equally would produce bad results, because it'd make the second button (the one with a wider label) overflow, while giving the first button space that it doesn't really need. This is shown in the last example on my jsfiddle. This is a bad, overflowy default behavior for "flex: 1" to have. The flex algorithm *can cleanly account for this* by clamping to the "min-width", but for that to work, we have to have a sane, nonzero min-width value to clamp to.  So, the spec gives flex items a probably-sane min-width value, by default. This lets us handle this scenario gracefully by preventing the wide-label button from being too small, while allowing the "OK" button to be smaller.

There are other scenarios involving "flex-shrink" as well (which defaults to 1, which means flex items will shrink below their flex-basis by default), but I won't get into them here. Essentially, "min-width:auto" makes common cases easy, at the cost of making complex cases require "min-width:0" hack.