Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

zgreen opened this issue Oct 15, 2015 · 4 comments


Copy link

@zgreen zgreen commented Oct 15, 2015

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).

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.


This comment has been minimized.

Copy link

@philipwalton philipwalton commented Oct 16, 2015

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.


This comment has been minimized.

Copy link

@bramus bramus commented Jul 31, 2017

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:

As recommended above it's easy to bypass this issue by nesting an extra element inside your flex item. Here's a simple demo:


This comment has been minimized.

Copy link

@bramus bramus commented Jan 31, 2018

As per w3c/csswg-drafts#2085 (comment) and w3c/csswg-drafts#2085 (comment): 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.


This comment has been minimized.

Copy link

@bramus bramus commented Jan 31, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.