Bug 97747 – width on a flexitem should not affect the min-width: auto constraint

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Daniel Holbert]

Midori 0.4.3
Chrome Version 23.0.1271.6 dev

[Daniel Holbert]

(sorry, accidentally bumped "enter" key while typing bug summary & filed bug prematurely)

The flexbox spec says that "min-width:auto" on a flex item is supposed to resolve to the min-content width.

However, when there's a "width" property-value specified on the item, webkit appears to be clamping to that width, instead of to the min-content width.

Testcases coming up.

[Daniel Holbert]

Created attachment 165909 [details]
testcase 1

This testcase has a block with:
        flex: 1 1 0px;
        width: 1000px;
inside of a 50px-wide flexbox. (with -webkit and -moz prefixes on flex properties)

I believe the "width: 1000px" there should have no effect. It's not used as the flex-base, clearly, because we have "0px" in the flex specification.  It's also not part of the block's min-content width, unless I'm misunderstanding what the spec authors had in mind with "min-content width".

[Daniel Holbert]

Created attachment 165910 [details]
reference case 1

Here's a reference case, with the "width: 1000px" removed.

I'd expect the testcase to render just like this reference case -- the 1000px shouldn't impact the minimum size that we clamp shrinkage at.

Relevant spec text:
  # auto
  #  When used as the value of a flex item's min main size property,
  # this keyword indicates a minimum of the min-content size, to help
  # ensure that the item is large enough to fit its contents.
  #
  # It is intended that this will compute to the ‘min-content’ keyword
  # when the specification defining it (Writing Modes Appendix D) is
  # sufficiently mature. 

So "min-width: auto" is supposed to effectively compute to "min-width: min-content".

And when we resolve "min-width: min-content", I believe we're supposed to only use the contents of the block -- the computed value of "width" shouldn't affect the calculation.  (If it did, then "width: min-content" would have a circular dependency.)

[Ojan Vafai]

Thanks for filing the bug! I think we just didn't test cases of setting both the flex-basis and the width to fixed values

[Ojan Vafai]

I take it back. You're totally right. We're using the width value for min-width:auto.

Same as testcase 1, but with min-width:0 on the flex items:
http://plexode.com/u/#N!(-webkit-Qj!dotted!b2_div2Z%3C2X%3EYW)height659)EVwidth62U(!!2R%0AIPH61!1!92O%3BrM4%22HboxKU4%22ELhould!EK%22XQJ)display66HflexEGaaaaaaE90pxOb8Z%2F_X66%3A!n4Z_!class%3DA)U!!I(R!!!!2!%20~http://plexode.com/eval3/#ht=!!ZstyleXU_.Hbox!%7BWV59R)border62pxjlackORJ-moz-HOJ!(HOJHOU%7DU_.a!%7B)-moz-P)!(P)PR)V1009!%2F*!SLhave!no!effect!*%2F)min-V0OWbackground6tealOU%7D(Z%2FstyleX(This!sLbe!a!50px-by-50px!teal!square.!ZbrX(No!teal!sLbe!outside!thejorder.(MaKaaa8(8R(This!_!sLonly!be!as!wide!as!the!text!it!contains.(MaKGGGGGG8(8R

[Daniel Holbert]

It's been ~4 months since the last comment here -- any updates / ETA for this?  Just want to make sure this doesn't fall off the radar, since I think this could lead to interop issues & developer confusion.

(I just received an email today regarding a testcase that rendered differently in Gecko vs. WebKit, and it ended up being due to this bug.)

Per comment 5, it seems like this should at least be upgraded from UNCONFIRMED to NEW or something. :)

[Tony Chang]

Ojan is working on this, he got side tracked by mathml :)

[Ojan Vafai]

Yup. I'm finally getting back to this. FWIW, I have been working on this and committing related patches. It's just that the fix requires rewriting a bunch of code. The final patch will be the one that fixes this as a one-liner. :) I'll try to get this done ASAP.

[Ojan Vafai]

The spec has changed and this will be fixed with bug 111790.

*** This bug has been marked as a duplicate of bug 111790 ***