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?
I'd like to get a link to a bug report, if available.
Right now, for my purposes, adding flex-shrink: 0
to in this reduced example: navbar, solves the problem, but I'd like to know if this would also work in future once the bug may be fixed...
#fixed {
position: fixed;
top: 0;
right: 0;
bottom: 0;
left: 0;
}
#tall {
height: 300%;
}
.outline {
outline: 1px solid red;
}
<link href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css" rel="stylesheet" />
<div id="fixed" class="d-flex flex-column">
<nav class="navbar outline">
<a class="btn btn-secondary">Button</a>
</nav>
<div id="tall"></div>
</div>
There is a discrepancy but
flex-shrink
doesn't appear to be the cause.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 tomin-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 toflex-shrink: 1
andmin-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 toheight: 300%
. This item is much taller than the container. However, withflex-shrink: 1
there can be no overflow. All items with a non-zeroflex-shrink
must reduce their size to prevent themselves and their siblings from overflowing the container (assuming the size of the content allows this). But withmin-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 aheight: 300%
, cannot overflow the container because offlex-shrink
. Its sibling, the.navbar
item, must also shrink because offlex-shrink
. However, it cannot shrink below the size of its content because ofmin-height: auto
. All good. Everything complies with the spec.Chrome
Like in Firefox, the
#tall
element, with aheight: 300%
, cannot overflow the container because offlex-shrink
. Its sibling, the.navbar
item, must also shrink because offlex-shrink
. However, it should not shrink below the size of its content because ofmin-height: auto
, but it does anyway. Why?Interventions
From my answer here:
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 withmin-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.