IE 11 has recently made an error with Flexbox. It was / still is working fine in IE10, but the latest browser has made the CSS Feature unusable for those users.
What happens:
When an image is a child of a flex item, it doesn't resize the height to auto when specified, which doesn't keep the correct constraints when resizing for responsive elements.
Attached is an example of this:

Live example of the code in the screenshots:
http://codepen.io/boostnewmedia/full/kvtoF
Phil Walton ( Solved by Flexbox ) said "philwalton: @themiketee the most annoying thing is I reported it well before IE11 shipped and it didn’t make it in. Months later, it’s still not fixed."
Known issue for Microsoft dating back to 10/1/2013:
https://connect.microsoft.com/IE/feedback/details/802625/min-height-and-flexbox-flex-direction-column-dont-work-together-in-ie-10-11-preview#tabs
They have dropped the ball again.
Is this using the modern (standard) syntax, or the IE 10 “tweener” syntax?
I believe IE11 is using the modern syntax, as it is not prefixed anymore.
I will double check in the morning when I get to work.
Tough one… not sure if this bug is enough to brand IE 11 has not supporting flexbox at all – but I appreciate it’s quite a common use case.
They sure support it, but they made a meal of it :D
sounds like a note/knownBug to me...
The detects are supposed to cover the "90% use case". If IE11's support doesn't actually fit the 90% use case, then should we add a userAgent blacklist to the detect?
IE11 has purposely made their UA string quite generic and hard to sniff
I believe we should list this as a knownBug and offer a link to some code to help block IE11 if this issue is a deal breaker for someone relying on flexbox.
If we _wanted_ to sniff for it, wouldn't Trident, combined with checking the rv value be enough?
but +1 to @ryanseddon's suggestion
Microsoft has made a fix in Internet Explorer for this issue: https://connect.microsoft.com/IE/feedback/details/802625
Awesome! I don't see any mention of a fix other than your own,
though. Could you give more information? Thanks a lot!
patrick
If they fix this in IE12, then would be blacklist IE11?
And if they fix this in an update to IE11, should we enhance the feature-detect so that it detects this bug?
If it _is_ fixed, then thats all the more reason not to blacklist. Ideally
we will be able to detect the fix in a lightweight manner, and add that to
the detect.
patrick
On Tue, May 13, 2014 at 4:47 PM, Ron Waldon [email protected]:
If they fix this in IE12, then would be blacklist IE11?
And if they fix this in an update to IE11, should we enhance the
feature-detect so that it detects this bug?—
Reply to this email directly or view it on GitHubhttps://github.com/Modernizr/Modernizr/issues/1301#issuecomment-43010458
.
patrick
@JunlinZhu
As @patrickkettner noted, I don't see a fix for it other than your comment stating that fact :)
I updated IE11 and no fix as of yet.
Thanks for looking into this guys, I'm closely following the conversation and I'm really happy you guys are looking into a possible fix.
Just an update.
I use flexbox to nicely fill empty areas of content. This falls back nicely for browsers that don't support flex box.
Below is some code to help with my issue, as it detects the browser, then adds .no-flexbox for the versions of IE:
if (navigator.userAgent.match(/msie|trident/i) ){
$('html').removeClass('flexbox').addClass('no-flexbox');
}
I would rather it just work as it should, but it doesn't
Example of how IE10 & 11 support Flexbox:

ping @JunlinZhu - could you elaborate on your guys' fix?
I think it would be extremely out of character for Microsoft to fix a feature mid-way through the generation of a product. They do patch security vulnerabilities, but they typically leave everything else alone.
I'd say we're waiting for Internet Explorer 11.5 (if there is one) or 12.0 for this fix. I'm also extremely keen to hear what @JunlinZhu is able to add.
I decided to start tweeting them everyday till I heard a response. Greg directed me to the feedback page so I can keep up to date. It has been active for quite a while now, but nothing.

I have a feeling the fix that @JunlinZhu has identified is "In all other browsers that support flexbox, a flex-direction:column based flex container will honor the containers min-height to calculate flex-grow lengths. In IE10 & 11-preview it only seems to work with an explicit height value."
Which doesn't sound like a fix.
@jokeyrhyme
If they are waiting to release a new version, we are in danger of having users still using the browsers with broken functionality. :-1:
I have a feeling the fix that @JunlinZhu has identified is ...
For what its worth, googling his name turns up a MS employee stuff. quite possible he is aware of an unreleased update.
If they are waiting to release a new version, we are in danger of having users still using the browsers with broken functionality. :-1:
FWIW, IE 11 auto updates by default. 11 -> 12 is not going to be anything like 6 -> 7
We'll still have to deal with aggressive IT fiefdoms that block automatic updates, although that applies just as equally to Chrome and Firefox.
Anyone checked the status of this bug in the new IE developer channel? http://devchannel.modern.ie
yep. no update :[
Hey everyone,
I am the new owner of layout in regards to Flexbox on the IE team and wanted to address some of the questions as well as clarify a couple things.
The OP is actually referring to two different issues, one is a bug and the other is a spec issue. The one submitted by philwalton is directly related to using min-height on a flex container and its descendants respecting that height. This seems to be the same problem that @michaeltrilford is referencing in regards to his screenshots. This one is known, and is in development and still needs to go through thorough testing to ensure there are no regressions.
The other one is the issue where the images are flex-items themselves and are stretching to fill the container but not maintaining their intrinsic aspect ratio. After seeing this issue brought up by your team I brought it up to the working group and it was agreed that this is indeed a spec issue in regards to min-content on the sizing spec. We agreed that Chrome/FF's behavior was the preferred (no one wants images to default to a distorted state), but if you make Chrome follow the min-content aspect of the spec that existed at that time you actually get the same results that IE was displaying. The spec editors have updated the editor's draft with a section devoted to intrinsic sizing and added this information to implied minimum size of flex items. Updating our flex implementation to adherence to these spec updates is underway as well.
Thank you so much for reaching out to us regarding these issues (not just for IE, but the flex spec as a whole), and as I get more information regarding when we will ship these updates I will let you guys know. Feel free to reach out to me with any questions you may have on twitter (@gregwhitworth).
Thanks again,
Greg
Wonderful update, thank you so much @gregwhitworth. _Very_ much appreciated
@gregwhitworth Thanks for the update! It is good to have some communications about the issue, glad you are the new owner, and I'm excited for a possible fix in the near future.
Any opinions, @gregwhitworth , on how we should settle the issue at hand? Can you think of a way to quickly detect the IE11 behaviour from JavaScript land? Or would we need to sniff the user-agent and blacklist IE11 (strictly last resort)? Or is this working for 90% of use cases, so we can just leave the default result in IE11 to be true?
Sorry for the barrage of questions. :) Extremely glad to have you involved. :)
@jokeyrhyme No problem on the barrage of questions. I took the time to investigate the issue @michaeltrilford was pointing to so that I could ensure that it was the known min-height bug and it isn't (that's a good thing though as you can fix this issue right now with a small tweak). The spec states the following for the flex shorthand:
A unitless zero that is not already preceded by two flex factors must be interpreted as a flex factor.
We are not treating the final zero in Philip's example correctly so we go into measuring which is where the bug for the overflow of text resides. This has already been fixed during our spec update work, but you guys can quickly address this issue on your own sites by changing the value for flex basis from a 0 to 0px and we will render the same as Chrome/FF. You can change it with your dev tools as well and see it working as expected on the live site (I commented the line that I changed in the fiddle).
The majority of the problems with flex that I have seen can be rectified by not nesting so many flex containers, or placing elements with intrinsic aspect ratio inside of an item instead of making those elements the flex-items.
Because of this, as with any new tech I would use flex for certain aspects of the site but definitely not for your complete layout at this point, and I would avoid nesting too many flex containers. The vendors will continue to work together to address interop issues and web developers will be able to use flex more extensively without running into interop issues.
I would personally say that IE does support flex (I know you're all shocked by that answer), but possibly call out ways to address these issues in an author's code. As for whether these use cases cover 90% of the use cases that is hard to say without quantitative data of flex usage; so I don't want to even guess at that.
Thanks.
@gregwhitworth seems like simple, practical advice there. Thanks!
So, either avoid the shorthand flex property and/or always specify units for flex-basis.
@michaeltrilford ? @patrickkettner ? Should we leave the detect the way it is and close this issue? How do we progress here?
Hello,
I totally agree with the nesting issue, as this is where my problems occur. If I create a basic layout, everything works fine in IE11, even in shorthand.
If I create a very basic layout using Flex, IE 11 renders it fine.

Captured in IE11.

Link to project: http://codepen.io/boostnewmedia/pen/aEicI ( The Sass is located right at the bottom in the CSS view )
But when a complex/nested layout comes into play, this is when the issues occur on IE.
If an object is nested quite deep, and a "column" layout is needed over the default "row", this is when the parent div collapses.
Here is an example of a "complex nested layout", and It is used to solve a common design problem of creating seamless layouts.

The broken example will still use the flex layout on the right, but the images and text overlapping each other, this occurs when flex-direction: column is applied.
Similar to this image below:

sounding more like an edge case to me, then (and therefore should just be closed oot). @stucox, thoughts?
For me it was fixed using just adding as workaround
-ms-flex-preferred-size: auto;
It is weird that worked, as Microsoft says that they removed the "-ms-" prefix. "Internet Explorer 11 no longer supports the Microsoft vendor prefix ("-ms-") version of the flex box properties."
I will try that out at some point, thanks.
However, I'm happy with injecting the class "no-flexbox" on to the body for the browsers in question. Their users can have a visually dull web experience.
Encountered the same issue posted by @michaeltrilford on Apr 13. I have found an easy way to fix this: setting min-height to any value except ( none or 0px or 1px or 0em ) solves this.
I just wanted to round this out, in the Windows 10 Tech Preview you can see the min-height issue and the 0 issue are resolved. The intrinsic aspect ratio unfortunately just missed this preview but on internal builds it no longer repros. Thanks again for reporting it @michaeltrilford
Awesome work Greg :-)
@i-fekete Thanks! It is really works! Amazing fix!
@gregwhitworth Appreciate the openness.
Did as @i-fekete said and it worked for me.
In my case, I was having issues with images. They were stretching when inside of a flexbox container. Thanks!
@joaopgrassi Yes, that was the original problem.
The solution of @i-fekete worked for me, too.
I can't thank you enough!
Thanks @i-fekete - Life saver!
Thank you @i-fekete
@i-fekete, thank you! It works for me too!
Adding overflow:hidden worked for me, although I had a problem with the width, not the height!
.flex-wrapper {display:flex; flex-wrap:wrap}
.flex-item {overflow:hidden}
Most helpful comment
Encountered the same issue posted by @michaeltrilford on Apr 13. I have found an easy way to fix this: setting min-height to any value except ( none or 0px or 1px or 0em ) solves this.