flex-shrink discrepancy between Firefox and Chrome

Question

The following reduced code sample renders differently on Firefox vs Chrome. Is this the result of a browser bug , and if so, which is rendering per spec, and which is not?

Answer 1

flex-shrink discrepancy between Firefox and Chrome

There is a discrepancy but flex-shrink doesn't appear to be the cause.

Is this the result of a browser bug, and if so, which is rendering per spec, and which is not?

It doesn't appear to be a bug. It looks more like an intervention, which is a deliberate deviation from the spec, and is being applied by Chrome.

---

flex-shrink: 1

An initial setting of a flex container is flex-shrink: 1, as defined by the flexbox spec. This means that flex items are permitted to shrink in order to avoid overflowing the container.

Both Chrome and Firefox adhere to this guidance. You can verify this in developer tools by checking the browser's default styles for flex items. Both Chrome and Firefox render your flex items with flex-shrink: 1.

For more details see: How does flex-shrink factor in padding and border-box?

---

min-height: auto

An initial setting of flex items in a column-direction container is min-height: auto. In a row-direction container the items are set to min-width: auto. This means that the default minimum size of a flex item is the size of its content or its specified length along the main axis.

Full more details see: Why don't flex items shrink past content size?

---

Your code

You have a column-direction flex container with two flex items: .navbar and #tall. In Chrome and Firefox, both items are set by default to flex-shrink: 1 and min-height: auto. I verified this using dev tools. Everything looks good so far; all settings are in compliance with the spec.

Here's where the discrepancy begins: The #tall item is set to height: 300%. This item is much taller than the container. However, with flex-shrink: 1 there can be no overflow. All items with a non-zero flex-shrink must reduce their size to prevent themselves and their siblings from overflowing the container (assuming the size of the content allows this). But with min-height: auto, the items cannot reduce their size below the height of their content.

All this works in Firefox. But why not in Chrome? Why is the .navbar item, which is being squeezed by #tall, shrinking below the size of its content (the button) in Chrome?

---

Firefox

As stated above, the #tall element, with a height: 300%, cannot overflow the container because of flex-shrink. Its sibling, the .navbar item, must also shrink because of flex-shrink. However, it cannot shrink below the size of its content because of min-height: auto. All good. Everything complies with the spec.

---

Chrome

Like in Firefox, the #tall element, with a height: 300%, cannot overflow the container because of flex-shrink. Its sibling, the .navbar item, must also shrink because of flex-shrink. However, it should not shrink below the size of its content because of min-height: auto, but it does anyway. Why?

---

Interventions

An intervention is when a user agent decides to deviate slightly from a standardized behavior in order to provide a greatly enhanced user experience.

source: https://github.com/WICG/interventions

From my answer here:

Since at least 2017, it appears that Chrome is either (1) reverting back to the min-width: 0 / min-height: 0 defaults, or (2) automatically applying the 0 defaults in certain situations based on a mystery algorithm. (This could be what they call an intervention.) As a result, many people are seeing their layout (especially desired scrollbars) work as expected in Chrome, but not in Firefox / Edge.

So, as stated in the beginning of this answer, the problem you're encountering is probably not a bug, but a deliberate deviation from the spec. It would be Firefox that is in full compliance with the spec.

---

Important Notes

It's important to note that I have no direct knowledge of the internal workings of Chrome, Firefox or any other browsers. I only believe Chrome is applying a min-height intervention based on my personal observations. It's a theory. More like an extrapolation. There is a possibility that I am not entirely (or even remotely?) correct. Chrome could be fiddling with min-height, flex-shrink and/or other properties. I don't know for sure.

It's also important to note that, because this behavior is not in accordance with the spec, it may not be reliable and can change at any time.