Bug 97747 - width on a flexitem should not affect the min-width: auto constraint
: width on a flexitem should not affect the min-width: auto constraint
Status: RESOLVED DUPLICATE of bug 111790
: WebKit
Layout and Rendering
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
:
:
: 106143
: 62048
  Show dependency treegraph
 
Reported: 2012-09-26 18:08 PST by
Modified: 2013-03-07 16:25 PST (History)


Attachments
testcase 1 (958 bytes, text/html)
2012-09-26 18:19 PST, Daniel Holbert
no flags Details
reference case 1 (905 bytes, text/html)
2012-09-26 18:29 PST, Daniel Holbert
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-09-26 18:08:08 PST
Midori 0.4.3
Chrome Version 23.0.1271.6 dev
------- Comment #1 From 2012-09-26 18:11:31 PST -------
(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.
------- Comment #2 From 2012-09-26 18:19:03 PST -------
Created an attachment (id=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".
------- Comment #3 From 2012-09-26 18:29:30 PST -------
Created an attachment (id=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.)
------- Comment #4 From 2012-09-26 21:15:20 PST -------
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
------- Comment #6 From 2013-01-28 15:34:53 PST -------
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. :)
------- Comment #7 From 2013-01-28 15:38:32 PST -------
Ojan is working on this, he got side tracked by mathml :)
------- Comment #8 From 2013-01-28 16:06:48 PST -------
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.
------- Comment #9 From 2013-03-07 16:25:22 PST -------
The spec has changed and this will be fixed with bug 111790.

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