Width calculation and overflow errors with flexbox in Firefox - IE - Opera

Hi,

I’ve managed to identify an issue that happens when a slick carousel is initialized inside a flex item (child of a display: flex container, with flex: 1 auto).

It’s quite hard to describe what happens, basically, instead of being limited by width constraints of parent elements (e.g. the width of the body), the carousel forces the flex item to stretch indefinitely, thus stretching its parent with it.

Noticed that the .slick-track is assigned a huge width, which is only recalculated as a higher value every time the window resizes (and probably slick reinitializes).

Also, the .slick-list, which in Chrome/Safari respects the overflow: hidden rule and only stretches as far as is allowed by its container, in Firefox / IE / Opera it expands as far as the .slick-track.

Can confirm that forcing max-width: 100% on the flex item limits its width to that of its parent, but it does not take into account the other children of the flex container.

Reproduced here: http://jsfiddle.net/uLqt4zmy/1/ Also attaching an attempt to limit the width in a typical flexbox usage pattern - reproducing the holy grail layout using a flexing and a non-flexing child: http://jsfiddle.net/uLqt4zmy/9/

Reproduced in Firefox 35 on OSX and Firefox 35 / IE 11 / Opera ?? on Windows.

Any idea what could be causing this?

[tibineagu]

Apparently this is caused by how the flex-items are supposed to behave, and Chrome is actually the one implementing the W3C spec wrongly.

This article will shed some more light on it: https://bugzilla.mozilla.org/show_bug.cgi?id=1108514

The solution is to add min-width: 0px; on the flex children and their expansion will be restricted to the overall layout. (no idea why that happens tho)

[fredec]

2 days struggling with this problem. Just min-width: 0px; - Thank God!