1056203 - Setting an img's width to a percentage inside a div ordered by old-style css flexbox (-moz-box) adds extra height to the div?

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[donrhummy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

Full code can be seen here: http://stackoverflow.com/questions/25334026/why-does-setting-an-imgs-width-to-a-percentage-inside-a-div-ordered-by-css-flex

You can see the extra height from using percentage for the width here:

http://jsfiddle.net/080xzqub/

And if you instead set a pixel width, it has no extra height:

http://jsfiddle.net/080xzqub/1/


Actual results:

Parent div gets extra height beyond the image element only when using percentage width on the img element.


Expected results:

There should be no extra height. Chrome does not have the extra height.

Comment 1

[Daniel Holbert [:dholbert]]

It looks like the (vertical) -moz-box element determines its width by asking its child what its desired width is, and the child asks *its* child what its desired width is, and in this case that innermost child is the <img>, and it reports back its intrinsic width, or its specified width if there is one and it's definite.

In this case, there is a specified width (the percentage), but the percentage has nothing to resolve against, since the thing it would resolve against (the containing block's size) is what we're trying to measure.  So, this percentage is ignored for the purposes of determining the parent's size, and we instead return the image's intrinsic width (which is huge, for the image used in the jsfiddle).

Then, when we actually size the <img>, we have something to resolve against, and we use it.

(Something like this, at least. The XUL / -moz-box layout code is pretty old, and I haven't looked at it much, but I imagine this is essentially what's going on.)

Comment 2

[Daniel Holbert [:dholbert]]

(So, the -moz-box ends up being large as a result of comment 1 [clamped to the available width], and its child (the div) stretches to fill it, and then the img resolves its % width against that div's width.)

Note that this is conceptually similar to a scenario without -moz-box at all, but instead having a floated div that contains an <img> with a percent width. In both cases, the container has to determine its size based just on the contents, and ignores the %-width on the img; and then after the container has established a size, the img resolves its percent against that.  Chrome and Firefox agree on this in the floated-div-with-an-img case -- they both match the behavior corresponding to what Firefox does in the -moz-box case.

Comment 3

[Daniel Holbert [:dholbert]]

(Oh, sorry -- I totally misread the original bug. I thought it was asking about the extra *width*. Probably ignore comments 1 and 2.)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a testcase. The purple-bordered div (the parent of the <img>) is really tall, for no clear reason.

Hover the black <img> to see what it looks like with a pixel-valued height on the <img>.  (The purple-bordered div snaps to shrinkwrap the <img>.)

It looks like we're getting the main size (the height) of the <img>'s parent by treating "50%" as 50% of the image's intrinsic width, and then converting that into a height with the img's aspect ratio (which happens to be 1:1). So we end up sizing the purple div to half of the image's intrinsic size, basically.

This does indeed seem odd, but given that -moz-box is un-specified and discouraged these days (in favor of CSS flexbox, aka "display:flex"), this probably isn't high-enough priority to dig much further into at the moment, unless there's evidence that this is actually breaking real sites in ways that can't be worked around.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I don't think we should be changing the behavior of -moz-box, ever.  If actual CSS flexbox does not have a problem here, we should just wontfix this bug.

Comment 6

[Daniel Holbert [:dholbert]]

Yeah, if I add "display:flex; flex-direction: column" on the attached testcase, we get the expected result -- the purple-bordered div honors its "height" and is 100px tall instead of being huge.

Similarly, on the original jsfiddle ( http://jsfiddle.net/080xzqub/ ), the yellow div (with class="b") ends up honoring its height="200px", as you'd probably expect it to:
 http://jsfiddle.net/080xzqub/11/

The <img> overflows and sticks off the bottom, depending on how wide the viewport is (i.e. how large the image's percent-based-width ends up making it). It's correct (with CSS flexbox) that it overflows, given that its parent (the flex item) has a fixed height.

So, resolving this as WONTFIX, as suggested in comment 5.  Best practice going forward is to use CSS flexbox ("display:flex") -- and file bugs if you find that not behaving as you think it should.