Filing this bug to track any fallout from bug 984711 & bug 1037177, which added some fancy min-sizing behavior for flex items. (spec reference: http://dev.w3.org/csswg/css-flexbox/#min-size-auto ) I'm expecting that some content will break as a result of this change, though hopefully not very much. (and hopefully "min-width:0;min-height:0;" on the flex item in question should be sufficient to fix the bustage, in each case.)

(In reply to Daniel Holbert [:dholbert] from comment #0) > Filing this bug to track any fallout from bug 984711 & bug 1037177, which > added some fancy min-sizing behavior for flex items. Sorry, meant to include bug 1015474 there (which is the main bug for the new behavior). I've marked this bug as blocking bug 1015474, since all fallout from this is effectively "caused by" that bug.

My idea with this bug is as follows: (A) For bugs where content is broken by the introduction of "min-width:auto"/"min-height:auto" (and presumably just need a correctly-placed "min-width:0" or "min-height:0"): Those bugs should block this bug here. (B) For bugs that are actual Gecko bugs, caused by bug 1015474 incorrectly implementing the spec or otherwise breaking something in Gecko: Those bugs should block bug 1015474. I'm assuming there will be multiple bugs in category (A) (blocking this bug), in gaia and probably also in some web content (which I guess should be filed as tech evang bugs). There will hopefully be few (or no) bugs in category (B) -- but, it's worth conceptually separating any such bugs from those in category (A). Hence the division.

(In reply to Daniel Holbert [:dholbert] from comment #2) > My idea with this bug is as follows: > > (A) For bugs where content is broken by the introduction of > "min-width:auto"/"min-height:auto" (and presumably just need a > correctly-placed "min-width:0" or "min-height:0"): Those bugs should block > this bug here. Would a well done flex-basis work too? > > (B) For bugs that are actual Gecko bugs, caused by bug 1015474 incorrectly > implementing the spec or otherwise breaking something in Gecko: Those bugs > should block bug 1015474. > > I'm assuming there will be multiple bugs in category (A) (blocking this > bug), in gaia and probably also in some web content (which I guess should be > filed as tech evang bugs). Could you please send a mail to dev-gaia about this?

(In reply to Julien Wajsberg [:julienw] from comment #3) > (In reply to Daniel Holbert [:dholbert] from comment #2) > Could you please send a mail to dev-gaia about this? Since we're seeing breakage in various places, I think this mail to dev-gaia is pretty important. I'll send one out now, and people can chime in if I get any details wrong. Thanks.

(In reply to Julien Wajsberg [:julienw] from comment #3) > Would a well done flex-basis work too? Nope. min-width (or min-height) trumps flex-basis. So if min-width (or min-height) ends up being something large (because it's coming from the min-content size, and the content is "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...aaa"), then the flex-basis won't make a difference. *However* - you're partially right -- a well-chosen *width*, combined with flex-basis:auto, WOULD help you in this scenario, because if you have flex-basis:auto (which says "use my 'width' property to get the flex-basis), then we won't let the resolved min-width be any larger than the 'width' property. So even if you have a really long stretch of content ("aaaaa..aaa"), the styling "width:1px" would suppress us from using the (large) min-content width as a minimum width, **IF** flex-basis is its default "auto" value. This exception is a bit confusing, but it's supposed to make this more intuitive & prevent cases where this unexpected min-width might bite folks. This exception is what this clause in the spec is talking about: # [min-width:auto] specifies as the minimum size the smallest of: # * the used flex-basis, if the computed flex-basis was 'main-size', # * [...other things...] (Note that 'flex-basis...main-size' there is equivalent to 'flex-basis...auto'. It was renamed (in the spec) a week or two ago, but I haven't changed our implementation yet because I didn't want to break too many things at once. :) (though I suspect that 'main-size' change will be unlikely to break things) (Also, for vertical flexboxes, replace "[min-]width" with "[min-]height" above, of course) (In reply to Kevin Grandon :kgrandon from comment #4) > I'll send one out now, and people can chime in if I get > any details wrong. Thanks. Thanks, Kevin!

FWIW, I posted to www-style about a commonality between some of these bugs ('overflow' being set on the grandchild of a flex container) here: http://lists.w3.org/Archives/Public/www-style/2014Jul/0589.html (This is at least the scenario in bug 1042887 and bug 1043318, and I think it's likely the case for others as well, though I'm 100% not sure because the grandchild's CSS isn't in the contextual region of the patches that landed.)