The "min-width:auto" language that I implemented/updated in bug 1015474 got rewritten in the spec in August, here: https://hg.csswg.org/drafts/rev/9b745a07d529#l1.33 The current (rewritten) spec language is here: http://dev.w3.org/csswg/css-flexbox-1/#valdef-min-width-min-height-auto At the time, I didn't think this latest rewrite actually changed the behavior much, but I just noticed that it actually did. Specifically: - The old language (which we have implemented) *only* considered the min-content size "if the item has no intrinsic aspect ratio". - Whereas, the new language *does* consider the min-content size *even if there's an intrinsic aspect ratio*. It defines "content size" as the "min-content size in the main axis, clamped, if it has an aspect ratio, by any definite min and max cross size properties converted through the aspect ratio, and then further clamped by the max main size property if that is definite." I posted to www-style to clarify why this change was made & if it was intentional (personally I prefer the old behavior for this case): https://lists.w3.org/Archives/Public/www-style/2015Feb/0485.html If the current spec language sticks, I'm filing this bug to implement that new language.

The current spec language is indeed sticking, as noted here: https://lists.w3.org/Archives/Public/www-style/2015Mar/0029.html

Note: this bug causes minor breakage in the Spotify web player's recently-updated DRM-enabled "flash-free" UI (which happens to be the UI that they show me, but not the one that they show everybody). e.g. if you visit this page with a skinny-ish browser window: https://open.spotify.com/search/results/coheed and look at the top 5 songs, the durations aren't aligned, particularly for songs with long names. The div with the song name (with class="tracklistcol name") refuses to shrink to be skinnier than the song name, despite having "flex: 1; width: 0;". If I manually add "min-width:0", then it'll cooperate and shrink (and allow text-overflow:ellipsis to take effect on one of its descendants), though -- and then everything aligns nicely. This is a form of this bug, as discussed in dupe bug 1331692.