Flex items with an explicit & definite "width" should not resolve their min-width:auto to anything larger than that width. We're not living up to this right now, for some reason. See attached testcase. STR: 1. Load attached testcase. EXPECTED RESULTS: black bordered area should be 100px wide. ACTUAL RESULTS: black bordered area is 60000px wide. Chrome 55 and Edge 14 give EXPECTED RESULTS. Firefox Nightly 53 gives ACTUAL RESULTS.

Ah, this chunk of spec-text was rewritten, as described in bug 1136312. In the old spec text (the red text in https://hg.csswg.org/drafts/rev/9b745a07d529#l1.33 ), min-width:auto is only supposed to consider explicit 'width' values "when flex-basis is set to [its initial value, called 'main-size' in that spec revision]". In this testcase, flex-basis is *not* set to its initial value, so we disregard the 'width', as required by that older version of the spec. But the newer version of the spec says that we should always take the explicit 'width' (or height) into account as an upper bound for what min-width:auto (min-height:auto) resolves to: https://drafts.csswg.org/css-flexbox-1/#valdef-min-width-min-height-auto So this is probably just a dupe of bug 1136312. (That bug focuses on items with intrinsic aspect ratios, which isn't what we're dealing with here -- but it's also more generally about this rewritten spec-section.)

Adding webcompat issue #9834 per https://webcompat.com/issues/9834#issuecomment-350018577.

Actually, this is more specifically a dupe of bug 1316534; updating dupe target. (Looks like my analysis in comment 1 here is basically the same as bug 1316534 comment 1.)