Heights for flexbox children intrinsically-sized with CSS are not computed properly in Firefox

[zgreen]

When using the CSS intrinsic-sizing method to force an element to maintain an exact aspect ratio, Firefox computes the height as 0px (tested Firefox 41.0.2 and Firefox Nightly).

• Example with two flex children (one intrinsically sized): http://codepen.io/zgreen/pen/XmeyXj/
• Example with one flex child (intrinsically sized): http://codepen.io/zgreen/pen/avLQBW

This might be related to Flexbug 5, I am not sure. The height for these intrinsically-sized flex children appear to be properly computed in IE11, Chrome 45.0.2454.101 (64-bit), and Safari 9.0.

[philipwalton]

I think there is still some dispute about the correct behavior here. As it stands now, percentage-based top/bottom paddings resolve against height on flex items, not width like they do on block items, which means the intrinsically-sized box method won't work on flex items. Though that may change.

Also, according to this thread, percentages that are based on the height of an element that is itself based on its content always resolve to 0, which is how Firefox is doing it today.

As a simple workaround, you can always just put a block element inside the flex item to avoid this issue altogether.

[bramus]

Late 2015 the spec got updated, now allowing both:

Percentage margins and paddings on flex items can be resolved against either:

1. their own axis (left/right percentages resolve against width, top/bottom resolve against height)
2. the inline axis (left/right/top/bottom percentages all resolve against width)

A User Agent must choose one of these two behaviors.

So it's not really a "flexbug", although it can leave one (including me) confused at first.

It is acknowledged in the spec itself that the “wiggle room” created by this change is not ideal:

Note: This behavior sucks, but it accurately captures the current state of the world. It is the CSSWG's intention that browsers will converge on one of the behaviors, at which time the spec will be amended to require that.

Above that it's also not advised to use the CSS intrinsic-sizing method method until this is resolved:

Advisement: Authors should avoid using percentages in paddings or margins on flex items entirely, as they will get different behavior in different browsers.

Related browser bugs:

• Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=229568
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=958714

As recommended above it's easy to bypass this issue by nesting an extra element inside your flex item. Here's a simple demo: https://codepen.io/bramus/pen/wqKbWq

[bramus]

As per https://github.com/w3c/csswg-drafts/issues/2085#issuecomment-360244244 and https://github.com/w3c/csswg-drafts/issues/2085#issuecomment-360602313: both Edge and Firefox have expressed their intent to implement the Blink/Webkit behavior.

Quoting @atanassov (Edge):

Our intention in Edge is to implement the blink and webkit behavior, i.e. resolve padding/margin-top/bottom values against the available inline size (width). Our decision is driven solely due to the compatibility issues experienced by our users.

Quoting @dholbert (Firefox):

We're going to change as well (away from the symmetric behavior, to the inline-axis behavior).

There's a lot of activity going on on the Firefox-related bug so I guess there's a chance we might see this change land rather soon.

[bramus]

The relating Firefox bug just got closed and marked as resolved. The changes are planned to ship with the release of Firefox 60.