6

I have some code which currently renders properly on Chrome Stable. I have received reports of the code working incorrectly on Beta and Dev and I am able to reproduce the issue on Canary. I found this PSA which appears related to my issue. So, I am working under the assumption this is a change to more closely follow spec rather than a bug.

My software only targets Google Chrome. So, a robust solution is not necessarily needed although it would be nice to have backwards compatibility.

The setup is:

  • Parent element has display:flex, flex-direction: column and has max-height applied to it.
  • A deep descendant of the parent exceeds the max-height

And the behavior change is:

  • On stable, max-height is enforced and child does not break out.
  • On canary, max-height is disregarded and child breaks out.

I am able to prevent the child from breaking out by applying max-height to the inner element. However, this is not desirable because I would need to reduce the value for max-height by the height of footer which isn't easily done in a non-contrived example.

The following code snippet highlights my issue:

.outer {
  display: flex;
  flex-direction: column;
  max-height: 410px;
}
.inner {
  display: flex;
  flex-direction: column;
}
.content {
  width: 200px;
  height: 500px;
  background-color: green;
}
.footer {
  height: 20px;
  width: 200px;
  background-color: red;
}
<div class='outer'>
  <div class='inner'>
    <div class='content'>
    </div>
  </div>
  <div class='footer'>
  </div>
</div>

Here is a screenshot of how this renders on Chrome Canary (left) vs Chrome Stable (right):

enter image description here

Is anyone able to tell me how to adjust this code such that inner + footer respect the max-height value of outer?

Sean Anderson
  • 27,963
  • 30
  • 126
  • 237
  • The content div is required. The actual HTML markup looks more like: https://gist.github.com/MeoMix/f6cbea85c7345236e74e where "#settingsDialog-panel" has the max-height property and it is attempting to contain content within it. Additionally, this change has broken multiple aspects of my code. I'm trying to understand what happened so that I can resolve the issue elsewhere. The layout of the HTML may vary in each instance. – Sean Anderson Apr 27 '15 at 23:41
  • Well, as mentioned in the description, it's not desirable to reduce the value of max-height by a fixed value as I'm loading dynamic content into the footer. Buttons, checkboxes, etc. I'd like to have its height inferred from its content rather than having to explicitly state its height. Kind of defeats the whole purpose of flex if I have to start specifying values. :( – Sean Anderson Apr 28 '15 at 00:13

1 Answers1

7

I believe I understand the issue, but I will build upon this answer more as I learn more about the solution.

This issue was introduced due to resolution of this bug filed against Chromium. The spec indicates that the default value of a flex container should be min-height: auto where as currently it is min-height: 0.

A specific comment addresses the fact that this is a breaking change against all production websites and references a suggested change:

The change is:

In case this patch breaks any website or chrome UI, the fix is likely to add:

min-width: 0;

min-height: 0;

Applying min-height: 0 to .inner resulted in a layout consistent with what I currently see on stable.

Sean Anderson
  • 27,963
  • 30
  • 126
  • 237
  • 1
    Ah, makes sense. This was a problem when [Firefox changed its min values to auto as well](https://developer.mozilla.org/en-US/Firefox/Releases/34/Site_Compatibility#CSS) -- [here is related question about Firefox](http://stackoverflow.com/q/27424831/2930477) – misterManSam Apr 28 '15 at 03:07