1139931 - max-width for an img breaks Flexbox item width

Status: RESOLVED DUPLICATE of bug 823483

(Core :: Layout, defect)

Description

[Mathias Schäfer]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150222232811

Steps to reproduce:

Open http://codepen.io/molily/pen/ZYjPZZ?editors=110
There are three Flexbox examples, the first and the second are for reference only. The third triggers the bug.
The third example has div and img elements in it with max-width: 50%.


Actual results:

- The layout of the third flex container is broken, each flex item takes 100% of the flex container.
- The image and the div have a width of 1000px, which is 50% of the image’s intrinsic width, not 50% of the container box (the flex item).


Expected results:

I don’t know what the specs say, but AFAIK max-width for images should work the same in flex items as it does anywhere else.

My expectation: The third example layout should look the same as the first and the second. The horizontal space should be distributed equally between the flex items (since there are three items, each should take 1/3 of the available width). The images should take 50% of the container width.

The intrinsic width of the image should be irrelevant AFAIK for the calculated image width.

See also how Chrome 41 renderes the examples. Chrome renders the page according to my expectation.

Comment 1

[Daniel Holbert [:dholbert]]

I believe this is an instance of bug 1043520, combined with another rendering difference between Chrome & Firefox.

tl;dr, the problem goes away if you specify "min-width:0" on your flex item. Here's your codepen with that changed:
  http://codepen.io/anon/pen/myGrMp

min-width:0 disables the "min-width: auto" behavior on flex items (which chrome hasn't implemented yet). Basically, that behavior prevents flex items from shrinking below the minimum size of their contents.

I'm not sure offhand why "max-width: 50%" and "width: 50%" are treated differently in Gecko, when we're establishing intrinsic widths -- but that does seem to happen consistently, e.g. in floats, and IE matches our behavior there (though Chrome does not -- that's the other rendering difference I mentioned in the first line of this comment).

That difference between percent values for max-width & width (when establishing a parent's intrinsic size) may be a bug -- I'm not sure. But given that IE matches our behavior, it seems reasonable to suspect that we & IE are correct on that, & Chrome is incorrect.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (no flexbox): demonstrating difference between percent-valued "width" vs "max-width" when calculating parent's intrinsic size

Here's a testcase demonstrating the width:% vs max-width:% difference. (which IE agrees with us on -- and Opera 12.16 [before they switched to Blink] does as well).

Chrome seems to be the odd one out on this, which makes me suspect it's a Blink bug.

Comment 3

[Mathias Schäfer]

Thanks for your investigation.

Although the browsers behave differently, I’d say the are all correct since the behavior is undefined:
“The percentage is calculated with respect to the width of the generated box's containing block. If the containing block's width is negative, the used value is zero. If the containing block's width depends on this element's width, then the resulting layout is undefined in CSS 2.1.” – http://www.w3.org/TR/CSS21/visudet.html#min-max-widths

At least in your float example, the containing block’s width depends on the image’s width, so browsers are free to use the intrinsic width. In contrast, Chrome and Safari seem to look for the next containing block that has a non-zero width.

I didn’t expect to see this behavior in a flex item with flex: 1 1 auto though.

Comment 4

[Damon Bauer]

Seeing this issue as well. Very simple test case here: http://codepen.io/damonbauer/pen/doLZWq

Adding "min-width: 0" to the flex item provides a work around as described in Comment 1.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So is this basically a duplicate of bug 823483, or at least dependent on it?

Comment 6

[Daniel Holbert [:dholbert]]

Yes, thanks. (per 2nd half of comment 1 [after "I'm not sure"] and per testcase attached in comment 2)