Bug 137730 – 100% height doesn't work within a flex item in a flexbox

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Adam Comella]

Repro Steps
1. Go to http://jsfiddle.net/mLkp7L1j/2/

Expected: Orange element is the same height as the blue element (100px)

Actual: The blue element is taller

This seems to be similar to this Chromium bug: https://code.google.com/p/chromium/issues/detail?id=411832

The bug does not repro in IE 11 or Firefox 32.

Tested in Safari Version 7.0.6 (9537.78.2).

[Adam Comella]

Details about the impact of this bug.

I consider this to be a bad flexbox bug which makes flexbox practically unusable when implementing or using reusable UI components (e.g. those from jQuery UI, jQuery Mobile, WinJS). Here are a couple of examples to illustrate.

Scenario 1: An app developer puts a reusable UI component within a flexbox

The app would have some markup that looks like this:
<div class="a-flexbox">
  <div class="a-flex-item">
    <div class="reusable-ui-component">
      <!-- implementation details of ui component -->
    </div>
  </div>
</div>

The UI component will not work correctly if it uses a percentage height (e.g. height: 100%) within its implementation details. To fix this, the app developer needs to dig into the implementation of the UI component and restyle it to not use percentage heights. Other options for the app developer would be to stop using flexbox or to stop using the UI component. None of these options are good solutions.

Example of real world repro: Putting a WinJS ListView (a reusable UI component) inside of a flexbox: http://codepen.io/anon/pen/rhzgi

Scenario 2: As part of its implementation details, a reusable UI component puts app content into a flex item. An app developer can't use percentage heights within that content.

The app would have some markup that looks like this:
<div class="a-reusable-ui-component-which-uses-flexbox">
  <div class="reusable-ui-components-flex-item">
    <div class="custom-app-content-which-uses-percentage-height"></div>
  </div>
</div>

The app's content will not size correctly because it uses a percentage height. To fix this, the app developer would have to notice that the UI component puts the app's content into a flex item and then would have to restyle the app content to use flexbox features for sizing (e.g. flex-grow, flex-shrink) instead of percentage heights. Alternatively, the developer could stop using the UI component. Neither solution is good.

Example of real world repro: Attempting to use percentage height in app content which is put inside of a WinJS Hub (a reusable UI component which uses a flexbox as an implementation detail): http://codepen.io/anon/pen/hgauy

==========

My examples were meant to illustrate that this flexbox bug makes it difficult for app developers to make use of reusable UI components (e.g. those provided by libraries like jQuery UI, jQuery Mobile, WinJS). While this flexbox bug exists, app developers are left with a few options:
  1. Dig into the implementation details of reusable UI components so that they can style their app and the component to work well together (everything needs to use flexbox sizing or percentage height sizing -- you can't mix them)
  2. Avoid reusable UI components
  3. App authors and reusable UI component authors avoid flexbox

That's how bad the bug looks from my perspective. I am very interested to hear if I am misunderstanding something or if an easy generic workaround exists.

==========

This repros in Chrome and Safari (chromium bug: https://code.google.com/p/chromium/issues/detail?id=428049).

This works in IE 11 and Firefox 33.

[Rick Zhou]

I have the same issue,
basically, if the size of element is affected by flexgrow flexshrink or stretch. then its children's percentage size will be based on the original size before the flex change, not based on element's final size.

Issue 411832 was marked as a duplicate of:
https://bugs.chromium.org/p/chromium/issues/detail?id=341310

It looks like chromium started to look into this issue and they have a potential patch.

[Fernando Gutiérrez]

I want to add my support to fix this bug. After it's fixed in blink, it would be a shame if we had to keep our workarounds just because of webkit.

[Radar WebKit Bug Importer]

<rdar://problem/25512818>

This is still unresolved in Safari, including the nightly. All other major browsers appear to have fixed this which can be verified by loading up http://people.mozilla.org/~dholbert/tests/flexbox/compat_tests/percent-height-grandchild-1.html. Safari is the only browser that still shows red and is not conforming to spec https://drafts.csswg.org/css-flexbox/#algo-stretch "If the flex item has align-self: stretch, redo layout for its contents, treating this used size as its definite cross size so that percentage-sized children can be resolved." Here's the chromium patch that resolved it https://chromium.googlesource.com/chromium/src/+/0702247984d85e123f0ad2074e69743c710050ad

[David Kilzer (:ddkilzer)]

Another request:
<https://twitter.com/b3zet/status/760072984971313152>

[Frederic Aubry]

+1 This is really holding us back. To the point that we are considering not supporting Safari.

[Sven]

The Bug is still alive, also in actual Safari and iOS10.
ALL other Browsers have fixed that.

It makes the Flexbox-Model complete useless for Safari. Please fix this now, after 2 years of this reported Bug.

[Eric Meyer]

I just stumbled across this bug the other day.  The major problem with this is that percentage values are accepted as valid.  So if I try to say something like:

    height: 30em; /* value for Safari */
    height: 100%; /* value for every other flexbox browser */

…then Safari accept the 100%, and then makes the element zero-height.

Anyone figured out a feature-detection method or CSS hack to get Safari the value it needs while ignoring the correct value it can’t handle correctly?

[Rob Simpson]

I have been working on a chat feature in our application and there was a defect submitted for this same issue. I was able to resolve the issue by using viewport height rather than percentage because of the issue with the parents needing to explicitly have 100 percent in order for percentage to work on the given element.

Had an issue with flexbox on Safari,
stumbled across https://bugs.chromium.org/p/chromium/issues/detail?id=428049 and ended up here. In 2016. With no response.

No wonder ppl say Safari is the new IE now.

[MattFromGer]

This bug is still present in Chrome v55!!

[Phil]

Bump!  Would be awesome if this was fixed soon.  As a developer of a major JavaScript framework, my users need to be able to specify percentage sizes on the elements that they put inside our flexbox-based layouts, without having to resort to using JS-based layouts or other hacks.  All other major browsers support percentage size children in flexbox layouts just fine - safari is the only one holding us back.

(In reply to comment #13)
> This bug is still present in Chrome v55!!

Actually if you remove the flex-basis of "auto" from the fiddle (just use "flex: 1 1"), you'll see that the percentage size works in Chrome.  This is a bug in Chrome -it behaves differently when flex-basis is explicitly set to "auto", even though "auto" is the default.  See https://bugs.chromium.org/p/chromium/issues/detail?id=680484

Bottom line - there is a way to achieve the correct result in Chrome by omitting "flex-basis: auto" from the flex declaration, but there is currently no way to make Safari behave correctly.

[MattFromGer]

(In reply to comment #14)
> Bottom line - there is a way to achieve the correct result in Chrome by
> omitting "flex-basis: auto" from the flex declaration, but there is
> currently no way to make Safari behave correctly.

Thank you for the clarification!

[Dave Hyatt]

Note we do "fail" the jsfiddle but pass the mozilla test now. I think the jsfiddle is wrong, and that our behavior is correct according to the spec. I kind of think the spec is wrong here though.

Anyway, we should match Chrome now.

(In reply to comment #16)
> Note we do "fail" the jsfiddle but pass the mozilla test now. I think the
> jsfiddle is wrong, and that our behavior is correct according to the spec. I
> kind of think the spec is wrong here though.
> 
> Anyway, we should match Chrome now.

You're the hero we deserve! :)

Will the fix land in upcoming Safari 10.1?

[Simon Fraser (smfr)]

We don't comment about the contents of future releases.

[Sam Sneddon [:gsnedders]]

(In reply to comment #16)
> Note we do "fail" the jsfiddle but pass the mozilla test now. I think the
> jsfiddle is wrong, and that our behavior is correct according to the spec. I
> kind of think the spec is wrong here though.
> 
> Anyway, we should match Chrome now.

FWIW, I posted to www-style about that not that long ago in <https://lists.w3.org/Archives/Public/www-style/2017Jan/0068.html>. No responses, though. The difference between Edge and Firefox v. Chrome and now Safari really sucks, and I'd love to see the incompatibility resolved given it keeps on biting developers (I'm pretty sure I agree the spec is wrong here).

[Chris Ashton]

Hi all – just to add I too am experiencing this bug on Safari desktop and mobile (10.1 and iOS 10.3.1). 

It would great if a fix for this could be deployed that matches the current functionality of Chrome / IE / Edge etc.

Thanks

[Vikrant Negi]

It is 2017 and we still have this bug on Safari. Does anyone have a viable workaround for this on safari?

[Chris Ashton]

(In reply to Vikrant Negi from comment #22)
> It is 2017 and we still have this bug on Safari. Does anyone have a viable
> workaround for this on safari?

Nope, and I'm still experiencing the issue...

[Simon Fraser (smfr)]

This bug is marked fixed. If you can still reproduce the problem, please re-open with a  link to a test case that shows the broken behavior, testing in the latest Safari Technology Preview build (32).

[Vikrant Negi]

(In reply to Simon Fraser (smfr) from comment #24)
> This bug is marked fixed. If you can still reproduce the problem, please
> re-open with a  link to a test case that shows the broken behavior, testing
> in the latest Safari Technology Preview build (32).

Great, it seems to be working fine in the Safari 11. I was looking in Safari 10. Thanks.

[Vikrant Negi]

(In reply to Chris Ashton from comment #23)
> (In reply to Vikrant Negi from comment #22)
> > It is 2017 and we still have this bug on Safari. Does anyone have a viable
> > workaround for this on safari?
> 
> Nope, and I'm still experiencing the issue...

They seem to have fixed this issue in Safari 11. Check out the Safari Technology preview to test it. Works fine.
https://developer.apple.com/safari/download/

[Kanchan Khurana]

In Safari version 10.1.2, It is not working. Is there any solution to this?

[David Kilzer (:ddkilzer)]

(In reply to Kanchan Khurana from comment #27)
> In Safari version 10.1.2, It is not working. Is there any solution to this?

Please file a new bug with a test case as this bug is marked as resolved.  Thanks!