1043520 - (minsizeauto-fallout) Tracking bug for web content breaking due to new "min-width:auto" / "min-height:auto" behavior on flex items

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

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.)

Comment 1

[Daniel Holbert [:dholbert]]

(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.

Comment 2

[Daniel Holbert [:dholbert]]

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.

Comment 3

[Julien Wajsberg [:julienw]]

(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?

Comment 4

[Kevin Grandon :kgrandon]

(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.

Comment 5

[Daniel Holbert [:dholbert]]

(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!

Comment 6

[Daniel Holbert [:dholbert]]

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.)

Comment 7

[Daniel Holbert [:dholbert]]

Closing out this tracking bug; this was focused on a behavior change that we shipped before other engines nearly a decade ago, which had some webcompat fallout while were the only ones implementing the new behavior.

Other browsers did end up implementing the change, and the spec has evolved further since then, so any associated breakage at this point should get its own bug and wouldn't make sense to associate with this tracking bug.