auto"? from Ojan Vafai on 2013-01-07 (www-style@w3.org from January 2013) (original) (raw)
Ugh. I spoke too soon. I went to fix this and realized that this is a more general problem than just the flexbox issue. There are a couple questions that are not clearly spelled out in the spec when you specify both min-width and width.
- Should container always always be 100px or should min-content override it?
- Should the min-content on the container use the child's min-content or it's 200px width?
Testcase: https://bug-106143-attachments.webkit.org/attachment.cgi?id=181530 Screenshot in IE9, FF17 and Chrome tip of tree: https://bug-106143-attachments.webkit.org/attachment.cgi?id=181529
I can see valid arguments for either of the three existing behaviors.
On Wed, Sep 26, 2012 at 9:42 PM, Daniel Holbert <dholbert@mozilla.com>wrote:
OK, thanks for the sanity-check!
~Daniel
On 09/26/2012 09:38 PM, Ojan Vafai wrote:
You're interpretation is correct. We just have a bug.
On Wed, Sep 26, 2012 at 9:08 PM, Daniel Holbert <dholbert@mozilla.com wrote:
Hi www-style,
Suppose you have this simple flex-item in a horizontal flex container:
abcwith no fancy style rules affecting it.So it has "min-width:auto" (the default), and that resolves to the min-content width -- in this case, the width of the text "abc".
NOW -- suppose we set "width" on the div, e.g.:
abcMY QUESTION: Does the "width" property there affect the used value of "min-width: auto" that we pass to the flex algorithm?
My interpretation: I don't think it should -- to me, the min-content width is a function of the div's contents, and it necessarily doesn't depend on the div's "width" property. (Otherwise, it seems that "width: min-content" would be problematic to define).
I'm asking because Webkit's current implementation[1] seems to disagree with me on this (they render the above flex-item as if it had "min-width: 1000px"), and I want to sanity-check my own understanding.
(For reference, I filed https://bugs.webkit.org/show_bug.cgi?id=97747on this, but that may or may not be a valid bug depending on the outcome of this thread.)
Thanks, ~Daniel [1] I tested Chrome dev channel, ver. "23.0.1271.6 dev", Linux x86_6