|Summary:||100% height doesn't work within a flex item in a flexbox|
|Product:||WebKit||Reporter:||Adam Comella <rigdern>|
|Component:||Layout and Rendering||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||bfulgham, chris, chrise524, damon, ddkilzer, eoconnor, eric, faubry, gsnedders, hyatt, johnson.liang, jonlee, khurana.kanchan1989, matthias.strauss, m.kurz+webkitbugs, pguerrant, rinick, rob.simpson, simon.fraser, sr, vikrantnegi007, webkit-bug-importer, zalan, zerks0|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.9|
Description Adam Comella 2014-10-14 19:56:05 PDT
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).
Comment 1 Adam Comella 2014-10-28 13:14:36 PDT
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.
Comment 2 Rick Zhou 2015-08-17 15:23:19 PDT
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.
Comment 3 chrise524 2016-02-26 19:20:16 PST
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.
Comment 4 Fernando Gutiérrez 2016-02-29 09:45:13 PST
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.
Comment 6 damon 2016-06-08 09:00:24 PDT
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
Comment 7 David Kilzer (:ddkilzer) 2016-08-01 10:15:41 PDT
Another request: <https://twitter.com/b3zet/status/760072984971313152>
Comment 8 Frederic Aubry 2016-08-31 14:16:44 PDT
+1 This is really holding us back. To the point that we are considering not supporting Safari.
Comment 9 Sven 2016-09-20 03:07:41 PDT
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.
Comment 10 Eric Meyer 2016-09-26 09:40:16 PDT
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?
Comment 11 Rob Simpson 2016-11-28 08:39:51 PST
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.
Comment 12 johnson.liang 2016-12-20 20:19:31 PST
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.
Comment 13 MattFromGer 2017-01-11 03:04:13 PST
This bug is still present in Chrome v55!!
Comment 14 Phil 2017-01-12 06:11:37 PST
Comment 15 MattFromGer 2017-01-12 06:52:12 PST
(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!
Comment 16 Dave Hyatt 2017-02-28 11:05:06 PST
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.
Comment 17 damon 2017-02-28 11:08:48 PST
(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! :)
Comment 18 m.kurz+webkitbugs 2017-02-28 14:11:46 PST
Will the fix land in upcoming Safari 10.1?
Comment 19 Simon Fraser (smfr) 2017-02-28 14:14:27 PST
We don't comment about the contents of future releases.
Comment 20 Sam Sneddon [:gsnedders] 2017-02-28 16:58:24 PST
(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).
Comment 21 Chris Ashton 2017-04-24 06:32:30 PDT
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
Comment 22 Vikrant Negi 2017-06-08 00:57:26 PDT
It is 2017 and we still have this bug on Safari. Does anyone have a viable workaround for this on safari?
Comment 23 Chris Ashton 2017-06-08 07:35:20 PDT
(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...
Comment 24 Simon Fraser (smfr) 2017-06-08 08:38:47 PDT
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).
Comment 25 Vikrant Negi 2017-06-08 23:28:22 PDT
(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.
Comment 26 Vikrant Negi 2017-06-08 23:29:35 PDT
(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/
Comment 27 Kanchan Khurana 2018-02-01 03:06:57 PST
In Safari version 10.1.2, It is not working. Is there any solution to this?