How can I make a display:flex container expand horizontally with its wrapped contents? - html

When using css flexbox the three main browsers appear to behave entirely differently in certain areas.
In this case I am trying to create a grid of images:
<div class="container">
<div class="photo"></div>
<div class="photo"></div>
<div class="photo"></div>
<div class="photo"></div>
<div class="photo"></div>
<div class="photo"></div>
</div>
.container {
display:inline-flex;
flex-flow : column wrap;
align-content : flex-start;
height : 100%;
}
In this example I need a container, itself containing several div elements set up to flow from top to bottom and wrapping when they reach the bottom. Ultimately providing me with columns of photos.
However I need the container to expand horizontally to accommodate the wrapped elements:
Here is a quick jsFiddle to demonstrate.
The behaviour is as follows:
IE 11 - Correct, the container stretches horizontally to wrap each column of wrapped elements
Firefox - The container only wraps the first column of elements, with the rest overflow out.
Chrome - The container always stretches to fill the width of its parent, whatever that may be.
In this instance I would like to achieve the behaviour of IE11 in the other two browsers. Therefore my question is, how can I make a flexbox container expand horizontally to match its column wrap contents.
Thanks in advance.

It's curious that most browsers haven't implemented column flex containers correctly, but the support for writing modes is reasonably good.
Therefore, you can use a row flex container with a vertical writing mode. This will swap the block direction with the inline direction, and thus the flex items will flow vertically. Then you only need to restore the horizontal writing mode inside the flex items.
.container {
display: inline-flex;
writing-mode: vertical-lr;
flex-wrap: wrap;
align-content: flex-start;
height: 350px;
background: blue;
}
.photo {
writing-mode: horizontal-tb;
width: 150px;
height: 100px;
background: red;
margin: 2px;
}
<div class="container">
<div class="photo">1</div>
<div class="photo">2</div>
<div class="photo">3</div>
<div class="photo">4</div>
<div class="photo">5</div>
<div class="photo">6</div>
<div class="photo">7</div>
<div class="photo">8</div>
<div class="photo">9</div>
</div>
This approach may have its own bugs in edge cases, especially if you mix advanced layout techniques like floats and nested flexboxs. But for most cases it seems to work properly.

The spec says that what you're doing should work, but it's implemented incorrectly in every major browser besides Internet Explorer / Edge, making multi-line inline-flex column layouts useless at present for most developers. Here's a Chromium bug report providing an example that is effectively identical to yours, and noting that it renders incorrectly in Chrome, Safari, and Firefox.
The argument from spec is more complicated than I'm able to understand, but the key point is that Flexible Box Layout Module Level 1 spec defines the intrinsic cross-size of a flex container (that is, the intrinsic height of a flex-direction: row flex container or the intrinsic width of a flex-direction: column flex container) in the section Flex Container Intrinsic Cross Size. There, it is stated:
For a multi-line flex container, the min-content/max-content cross size is the sum of the flex line cross sizes
That is, the intrinsic width of a flex-direction: column flex container should be the sum of the widths of its columns, as you'd expect. (There is more complexity than this, and I don't understand it all, but I believe the above to be broadly true.) However, Chrome, Firefox, and Safari all calculate this width incorrectly; setting width: min-content or width: max-content on a column wrap flex box in Chrome, you can clearly see that the width is set to the width of the widest single element.
A silly Chrome-specific workaround exists, but is probably best avoided. Until the bug is fixed, this part of the Flexbox model simply doesn't work as designed and there's no clean solution available.

It seems this issue cannot be solved only with CSS, so I propose you a JQuery solution
container width = position of the last child - position of the container + width of the last child (including margin)
Code :
$(document).ready(function() {
$('.container').each(function( index ) {
var lastChild = $(this).children().last();
var newWidth = lastChild.position().left - $(this).position().left + lastChild.outerWidth(true);
$(this).width(newWidth);
})
});
Demo :
http://jsfiddle.net/qzea320L/

You have a column layout distribution with a fixed height container.
When you set the flex-direction to column you define the Vertical axis as the main axis.
In flexbox that means it will fill up the available height and then create a new column.
In this JSBIN I use javascript to change the container's height and, because of that, you will see the child items move.
PS: you shouldn't rely on IE behavior since their flex support is recent.

Another possible approach:
.container {
column-count: 2; /*or whatever */
}
.container > div {
display: inline-block;
}
https://developer.mozilla.org/en-US/docs/Web/CSS/column-count
You may also need to adjust margin-top of .container > div:first-child if they don't align to the top.

Related

Vertically centering div in parent, flex adding undesired shrinking effect [duplicate]

There have been questions and articles about this, but nothing conclusive as far as I can tell. The best summary I could find is
flex-basis allows you to specify the initial/starting size of the element, before anything else is computed. It can either be a percentage or an absolute value.
...which in itself doesn't say much about the behavior of elements with flex-basis set. With my current knowledge of flexbox I don't see why that couldn't describe width also.
I'd like to know how exactly flex-basis is different from width in practice:
If I replace width with flex-basis(and vice versa), what will change visually?
What happens if I set both to a different value? What happens if they have the same value?
Are there some special cases where using either width or flex-basis would have a significant difference to using the other?
How do width and flex-basis differ when used in conjunction with other flexbox styles, such as flex-wrap, flex-grow and flex-shrink?
Any other significant differences?
Edit/clarification: This question has been asked in a different format in What exactly flex-basis property sets? but I felt a more direct comparison or summary of the differences of flex-basis and width (or height) would be nice.
Consider flex-direction
The first thing that comes to mind when reading your question is that flex-basis doesn't always apply to width.
When flex-direction is row, flex-basis controls width.
But when flex-direction is column, flex-basis controls height.
Key Differences
Here are some important differences between flex-basis and width / height:
flex-basis applies only to flex items. Flex containers (that aren't also flex items) will ignore flex-basis but can use width and height.
flex-basis works only on the main axis. For example, if you're in flex-direction: column, the width property would be needed for sizing flex items horizontally.
flex-basis has no effect on absolutely-positioned flex items. width and height properties would be necessary. Absolutely-positioned flex items do not participate in flex layout.
By using the flex property, three properties – flex-grow, flex-shrink and flex-basis – can be neatly combined into one declaration. Using width, the same rule would require multiple lines of code.
Browser Behavior
In terms of how they are rendered, there should be no difference between flex-basis and width, unless flex-basis is auto or content.
From the spec:
7.2.3. The flex-basis property
For all values other than auto and content, flex-basis is resolved the same way as width in horizontal writing modes.
But the impact of auto or content may be minimal or nothing at all. More from the spec:
auto
When specified on a flex item, the auto keyword retrieves the value
of the main size property as the used flex-basis. If that value is
itself auto, then the used value is content.
content
Indicates automatic sizing, based on the flex item’s content.
Note: This value was not present in the initial release of Flexible
Box Layout, and thus some older implementations will not support it.
The equivalent effect can be achieved by using auto together with a
main size (width or height) of auto.
So, according to the spec, flex-basis and width resolve identically, unless flex-basis is auto or content. In such cases, flex-basis may use content width (which, presumably, the width property would use, as well).
The flex-shrink factor
It's important to remember the initial settings of a flex container. Some of these settings include:
flex-direction: row - flex items will align horizontally
justify-content: flex-start - flex items will stack at the start of the line on the main axis
align-items: stretch - flex items will expand to cover the cross-size of the container
flex-wrap: nowrap - flex items are forced to stay in a single line
flex-shrink: 1 - a flex item is allowed to shrink
Note the last setting.
Because flex items are allowed to shrink by default (which prevents them from overflowing the container), the specified flex-basis / width / height may be overridden.
For example, flex-basis: 100px or width: 100px, coupled with flex-shrink: 1, will not necessarily be 100px.
To render the specified width – and keep it fixed – you will need to disable shrinking:
div {
width: 100px;
flex-shrink: 0;
}
OR
div {
flex-basis: 100px;
flex-shrink: 0;
}
OR, as recommended by the spec:
flex: 0 0 100px; /* don't grow, don't shrink, stay fixed at 100px */
7.2. Components of
Flexibility
Authors are encouraged to control flexibility using the flex shorthand
rather than with its longhand properties directly, as the shorthand
correctly resets any unspecified components to accommodate common
uses.
Browser Bugs
Some browsers have trouble sizing flex items in nested flex containers.
flex-basis ignored in a nested flex container. width works.
When using flex-basis, the container ignores the sizing of its children, and the children overflow the container. But with the width property, the container respects the sizing of its children and expands accordingly.
References:
Chrome does not expand flex parent according to children's content
Flex item overflowing when using flex-basis
Difference between width and flex-basis
Flex-basis is being ignored when sizing nested flex containers.
flex-basis:100px does something different from width:100px+flex-basis:auto
Examples:
https://jsfiddle.net/t419zhra/ (source: #Dremora)
https://codepen.io/anon/pen/NVxaoy (source #Daniel)
https://jsfiddle.net/voc9grx6/ (source: Chromium Bugs)
https://jsfiddle.net/qjpat9zk/ (source: Chromium Bugs)
flex items using flex-basis and white-space: nowrap overflow inline-flex container. width works.
It seems that a flex container set to inline-flex doesn't recognize flex-basis on a child when rendering a sibling with white-space: nowrap (although it could just be an item with undefined width). The container doesn't expand to accommodate the items.
But when the width property is used instead of flex-basis, the container respects the sizing of its children and expands accordingly. This is not a problem in IE11 and Edge.
References:
inline flex container width not growing
Inline flex container (display: inline-flex) is expanding the full width of parent container
Example:
https://jsfiddle.net/p18h0jxt/1/ (from first post above)
flex-basis (and flex-grow) not working on table element
References:
Why does flex-box work with a div, but not a table?
Why doesn't flex-grow: 1 work for a table in Safari? (and Edge)
flex-basis fails in Chrome and Firefox when the grandparent container is a shrink-to-fit element. The set-up works fine in Edge.
Absolutely positioned container not expanding width to fit flexbox content
Like in the example presented in the link above, involving position: absolute, the use of float and inline-block, will also render the same flawed output (jsfiddle demo).
Bugs affecting IE 10 and 11:
flex shorthand declarations with unitless flex-basis values are ignored
flex-basis doesn't account for box-sizing: border-box
flex-basis doesn't support calc()
Importance is ignored on flex-basis when using flex shorthand
In addition to Michael_B's excellent summary it's worth repeating this:
flex-basis allows you to specify the initial/starting size of the element, before anything else is computed. It can either be a percentage or an absolute value.
The important part here is initial.
By itself, this does resolve to width/height until the other flex grow/shrink properties come into play.
So. a child with
.child {
flex-basis:25%;
flex-grow:1;
}
will be 25% wide initially but then immediately expand as much as it can until the other elements are factored in. If there are none..it will be 100% wide/tall.
A quick demo:
.flex {
width: 80%;
margin: 1em auto;
height: 25px;
display: flex;
background: rebeccapurple;
}
.child {
flex-basis: auto;
/* default */
background: plum;
}
.value {
flex-basis: 25%;
}
.grow {
flex-grow: 1;
}
<div class="flex">
<div class="child auto">Some Content</div>
</div>
<div class="flex">
<div class="child value">Some Content</div>
</div>
<div class="flex">
<div class="child grow">Some Content</div>
</div>
Experimenting with the flex-grow, flex-shrink and flex-basis
(or the shorthand flex :fg fs fb)...can lead to some interesting results.
Nobody seems to mention that there is one key difference between flex-basis and width (or height, depending on the current writing mode), if we ignore the flexible sizing aspect (flex-grow: 0; flex-shrink: 0;).
It originates from the exception in Flex Layout, that the automatic minimum size for flex items defaults to min-content instead of zero, like usually. In other words, the default min-width: auto computes to min-content instead of 0.
The result is, that flex-basis is (by default) bound below by min-content. If you specify a value smaller than min-content, for example flex-basis: 0, it will compute to min-content. This essentially means that (by default) you can't make the box's content overflow, since the box has at least the size of the content.
This is a key difference to width, which can size the box arbitrarily small (by default), since min-width defaults to 0. If the value of width is smaller than min-content, the contents will overflow the box.
This behavior is mentioned in the spec, but only implicitly in the following comment at the wrong place at the end of 7.1.1. Basic Values of flex.
By default, flex items won’t shrink below their minimum content size (the length of the longest word or fixed-size element). To change this, set the min-width or min-height property. (See § 4.5 Automatic Minimum Size of Flex Items.)
As mentioned in the comment, setting a minimum size lowers the bound, and setting it to zero effectively disables it, making flex-basis behave again as expected.
But there are drawbacks. Firstly, there is no minimum size property for the main axis. You have to use the correct min-width/min-height or min-block-size/min-inline-size property for the current flex-direction. If you changed the flex-direction, you would need to again find the correct minimum size property.
Secondly, flex-basis can't be used anymore to distribute space towards proportionally sized boxes instead of simply adding to their initial size. For more details, see Figure 7 in the spec.
Here is a minimal example. Set min-width: 0 to make flex-basis behave as expected again.
.container {
display: flex;
}
.container div {
background-color: lightgrey;
border: 1px solid black;
margin: 0 10px;
/* disable any flexible sizing */
flex-grow: 0;
flex-shrink: 0;
/* TOGGLE ME */
/* min-width: 0; */
}
.mincontent {
width: min-content;
}
.smallerflexbasis {
flex-basis: 3ex;
}
.smallerwidth {
width: 3ex;
}
<div class="container">
<div class="mincontent">Lorem ipsum</div>
<div class="smallerflexbasis">Lorem ipsum</div>
<div class="smallerwidth">Lorem ipsum</div>
</div>
Possibly the most important point to add:
What if the browser doesn't support flex? In such a case, width/height take over and their values apply.
It is a very good idea - almost essential - to define width/height on elements, even if you then have a completely different value for flex-basis. Remember to test by disabling display:flex and seeing what you get.
It makes a difference if you're wrapping.
Say, you set a child to width:0 and expect it to wrap, well that's not going to happen. But with flex-basis:0 it will wrap. (provided overflow isn't hidden)
if you set a div's min-width:600px, if the window size goes under 600px, you will see a horizontal scrollbar which is not a good ux design.
If you set its flex-basis:600px, if the window size goes under 600px, that box will shrink and you will not see a horizontal bar.
Note that flex-basis applies only to the flex items.

line wrap when adding border to an inline-flex container [duplicate]

There have been questions and articles about this, but nothing conclusive as far as I can tell. The best summary I could find is
flex-basis allows you to specify the initial/starting size of the element, before anything else is computed. It can either be a percentage or an absolute value.
...which in itself doesn't say much about the behavior of elements with flex-basis set. With my current knowledge of flexbox I don't see why that couldn't describe width also.
I'd like to know how exactly flex-basis is different from width in practice:
If I replace width with flex-basis(and vice versa), what will change visually?
What happens if I set both to a different value? What happens if they have the same value?
Are there some special cases where using either width or flex-basis would have a significant difference to using the other?
How do width and flex-basis differ when used in conjunction with other flexbox styles, such as flex-wrap, flex-grow and flex-shrink?
Any other significant differences?
Edit/clarification: This question has been asked in a different format in What exactly flex-basis property sets? but I felt a more direct comparison or summary of the differences of flex-basis and width (or height) would be nice.
Consider flex-direction
The first thing that comes to mind when reading your question is that flex-basis doesn't always apply to width.
When flex-direction is row, flex-basis controls width.
But when flex-direction is column, flex-basis controls height.
Key Differences
Here are some important differences between flex-basis and width / height:
flex-basis applies only to flex items. Flex containers (that aren't also flex items) will ignore flex-basis but can use width and height.
flex-basis works only on the main axis. For example, if you're in flex-direction: column, the width property would be needed for sizing flex items horizontally.
flex-basis has no effect on absolutely-positioned flex items. width and height properties would be necessary. Absolutely-positioned flex items do not participate in flex layout.
By using the flex property, three properties – flex-grow, flex-shrink and flex-basis – can be neatly combined into one declaration. Using width, the same rule would require multiple lines of code.
Browser Behavior
In terms of how they are rendered, there should be no difference between flex-basis and width, unless flex-basis is auto or content.
From the spec:
7.2.3. The flex-basis property
For all values other than auto and content, flex-basis is resolved the same way as width in horizontal writing modes.
But the impact of auto or content may be minimal or nothing at all. More from the spec:
auto
When specified on a flex item, the auto keyword retrieves the value
of the main size property as the used flex-basis. If that value is
itself auto, then the used value is content.
content
Indicates automatic sizing, based on the flex item’s content.
Note: This value was not present in the initial release of Flexible
Box Layout, and thus some older implementations will not support it.
The equivalent effect can be achieved by using auto together with a
main size (width or height) of auto.
So, according to the spec, flex-basis and width resolve identically, unless flex-basis is auto or content. In such cases, flex-basis may use content width (which, presumably, the width property would use, as well).
The flex-shrink factor
It's important to remember the initial settings of a flex container. Some of these settings include:
flex-direction: row - flex items will align horizontally
justify-content: flex-start - flex items will stack at the start of the line on the main axis
align-items: stretch - flex items will expand to cover the cross-size of the container
flex-wrap: nowrap - flex items are forced to stay in a single line
flex-shrink: 1 - a flex item is allowed to shrink
Note the last setting.
Because flex items are allowed to shrink by default (which prevents them from overflowing the container), the specified flex-basis / width / height may be overridden.
For example, flex-basis: 100px or width: 100px, coupled with flex-shrink: 1, will not necessarily be 100px.
To render the specified width – and keep it fixed – you will need to disable shrinking:
div {
width: 100px;
flex-shrink: 0;
}
OR
div {
flex-basis: 100px;
flex-shrink: 0;
}
OR, as recommended by the spec:
flex: 0 0 100px; /* don't grow, don't shrink, stay fixed at 100px */
7.2. Components of
Flexibility
Authors are encouraged to control flexibility using the flex shorthand
rather than with its longhand properties directly, as the shorthand
correctly resets any unspecified components to accommodate common
uses.
Browser Bugs
Some browsers have trouble sizing flex items in nested flex containers.
flex-basis ignored in a nested flex container. width works.
When using flex-basis, the container ignores the sizing of its children, and the children overflow the container. But with the width property, the container respects the sizing of its children and expands accordingly.
References:
Chrome does not expand flex parent according to children's content
Flex item overflowing when using flex-basis
Difference between width and flex-basis
Flex-basis is being ignored when sizing nested flex containers.
flex-basis:100px does something different from width:100px+flex-basis:auto
Examples:
https://jsfiddle.net/t419zhra/ (source: #Dremora)
https://codepen.io/anon/pen/NVxaoy (source #Daniel)
https://jsfiddle.net/voc9grx6/ (source: Chromium Bugs)
https://jsfiddle.net/qjpat9zk/ (source: Chromium Bugs)
flex items using flex-basis and white-space: nowrap overflow inline-flex container. width works.
It seems that a flex container set to inline-flex doesn't recognize flex-basis on a child when rendering a sibling with white-space: nowrap (although it could just be an item with undefined width). The container doesn't expand to accommodate the items.
But when the width property is used instead of flex-basis, the container respects the sizing of its children and expands accordingly. This is not a problem in IE11 and Edge.
References:
inline flex container width not growing
Inline flex container (display: inline-flex) is expanding the full width of parent container
Example:
https://jsfiddle.net/p18h0jxt/1/ (from first post above)
flex-basis (and flex-grow) not working on table element
References:
Why does flex-box work with a div, but not a table?
Why doesn't flex-grow: 1 work for a table in Safari? (and Edge)
flex-basis fails in Chrome and Firefox when the grandparent container is a shrink-to-fit element. The set-up works fine in Edge.
Absolutely positioned container not expanding width to fit flexbox content
Like in the example presented in the link above, involving position: absolute, the use of float and inline-block, will also render the same flawed output (jsfiddle demo).
Bugs affecting IE 10 and 11:
flex shorthand declarations with unitless flex-basis values are ignored
flex-basis doesn't account for box-sizing: border-box
flex-basis doesn't support calc()
Importance is ignored on flex-basis when using flex shorthand
In addition to Michael_B's excellent summary it's worth repeating this:
flex-basis allows you to specify the initial/starting size of the element, before anything else is computed. It can either be a percentage or an absolute value.
The important part here is initial.
By itself, this does resolve to width/height until the other flex grow/shrink properties come into play.
So. a child with
.child {
flex-basis:25%;
flex-grow:1;
}
will be 25% wide initially but then immediately expand as much as it can until the other elements are factored in. If there are none..it will be 100% wide/tall.
A quick demo:
.flex {
width: 80%;
margin: 1em auto;
height: 25px;
display: flex;
background: rebeccapurple;
}
.child {
flex-basis: auto;
/* default */
background: plum;
}
.value {
flex-basis: 25%;
}
.grow {
flex-grow: 1;
}
<div class="flex">
<div class="child auto">Some Content</div>
</div>
<div class="flex">
<div class="child value">Some Content</div>
</div>
<div class="flex">
<div class="child grow">Some Content</div>
</div>
Experimenting with the flex-grow, flex-shrink and flex-basis
(or the shorthand flex :fg fs fb)...can lead to some interesting results.
Nobody seems to mention that there is one key difference between flex-basis and width (or height, depending on the current writing mode), if we ignore the flexible sizing aspect (flex-grow: 0; flex-shrink: 0;).
It originates from the exception in Flex Layout, that the automatic minimum size for flex items defaults to min-content instead of zero, like usually. In other words, the default min-width: auto computes to min-content instead of 0.
The result is, that flex-basis is (by default) bound below by min-content. If you specify a value smaller than min-content, for example flex-basis: 0, it will compute to min-content. This essentially means that (by default) you can't make the box's content overflow, since the box has at least the size of the content.
This is a key difference to width, which can size the box arbitrarily small (by default), since min-width defaults to 0. If the value of width is smaller than min-content, the contents will overflow the box.
This behavior is mentioned in the spec, but only implicitly in the following comment at the wrong place at the end of 7.1.1. Basic Values of flex.
By default, flex items won’t shrink below their minimum content size (the length of the longest word or fixed-size element). To change this, set the min-width or min-height property. (See § 4.5 Automatic Minimum Size of Flex Items.)
As mentioned in the comment, setting a minimum size lowers the bound, and setting it to zero effectively disables it, making flex-basis behave again as expected.
But there are drawbacks. Firstly, there is no minimum size property for the main axis. You have to use the correct min-width/min-height or min-block-size/min-inline-size property for the current flex-direction. If you changed the flex-direction, you would need to again find the correct minimum size property.
Secondly, flex-basis can't be used anymore to distribute space towards proportionally sized boxes instead of simply adding to their initial size. For more details, see Figure 7 in the spec.
Here is a minimal example. Set min-width: 0 to make flex-basis behave as expected again.
.container {
display: flex;
}
.container div {
background-color: lightgrey;
border: 1px solid black;
margin: 0 10px;
/* disable any flexible sizing */
flex-grow: 0;
flex-shrink: 0;
/* TOGGLE ME */
/* min-width: 0; */
}
.mincontent {
width: min-content;
}
.smallerflexbasis {
flex-basis: 3ex;
}
.smallerwidth {
width: 3ex;
}
<div class="container">
<div class="mincontent">Lorem ipsum</div>
<div class="smallerflexbasis">Lorem ipsum</div>
<div class="smallerwidth">Lorem ipsum</div>
</div>
Possibly the most important point to add:
What if the browser doesn't support flex? In such a case, width/height take over and their values apply.
It is a very good idea - almost essential - to define width/height on elements, even if you then have a completely different value for flex-basis. Remember to test by disabling display:flex and seeing what you get.
It makes a difference if you're wrapping.
Say, you set a child to width:0 and expect it to wrap, well that's not going to happen. But with flex-basis:0 it will wrap. (provided overflow isn't hidden)
if you set a div's min-width:600px, if the window size goes under 600px, you will see a horizontal scrollbar which is not a good ux design.
If you set its flex-basis:600px, if the window size goes under 600px, that box will shrink and you will not see a horizontal bar.
Note that flex-basis applies only to the flex items.

Chome - Deleting elements from height specified flexbox item display issue

I am having a chrome specific issue with removing elements from a flexbox item from a height specified flexbox container. This is causing strange display issues for another scrollable flexbox item within that container. It seems that the scrollable item is not properly refresh/repainting, while it is growing.
This is a fairly specific question that's easier to see in the example.
https://jsfiddle.net/gajv6snz/
Note: This is not specific to removing the elements using javascript. Manually deleting them in DevTools causes this also.
<div id="container">
<div id="box1"></div>
<div id="box2"></div>
</div>
#container {
height: 300px;
display: flex;
flex-direction: column;
}
/* Removing elements from #box1 causes display issues with box2 */
#box2 {
overflow-y: scroll;
}
I expect that bottom scrollable flexbox item to take over the full container once the top flexbox item has been emptied. I want the container to remain the same size throughout.

Flex-shrink not working as expected

I'm starting to work with flexbox, and, in order to understand flex-grow and flex-shrink, I used a simple program that displays two blocks and makes them take up the whole width using flex-grow: 2 in one of them and flex-grow: 1 in the other.
If I check the following line in the console: $(".one").width() === $(window).width() /3 it returns true. So far, so good.
The problem appears when I reduce the window size, because as soon as I do this the same line in the console ($(".one").width() === $(window).width() /3) starts returning false.
I know the default value for flex-shrink is 1. Wouldn't that mean that the proportions between both blocks would be maintained (since they are both being shrunk by the same amount)? Can anyone explain why this result happens?
Here's my code:
* {
font-family: verdana;
margin: 0;
}
body {
background: #eee;
}
.wrapper {
width: 100%;
max-width: 2000px;
margin: 0 auto;
}
.flex-container {
display: flex;
background-color: white;
}
.box {
height: 100px;
}
.one {
background-color: red;
flex-grow: 1;
}
.two {
background-color: blue;
flex-grow: 2;
}
<div class="wrapper">
<div class="flex-container">
<div class="box one"></div>
<div class="box two"></div>
</div>
</div>
While not relevant to your question it might be worth noting:
flex-wrap takes precedence over flex-shrink, unless the item is wider than the container.
So if you have flex-wrap enabled and you're expecting two items to shrink to fit side by side on a single row they won't, they'll wrap first even if there's plenty of shrink-potential.
If the item is wider than the parent container it can't wrap so it will shrink if it can.
You'd have to solve this with min/max widths, make the initial size smaller (this is probably the best way) or creating a new parent container without flex-wrap.
See also Is there any use for flex-shrink when flex-wrap is wrap?
flex-shrink is designed to distribute negative free space in the container.
In other words, it only works when flex items are big enough to overflow the container.
You're not having that problem here. There is no negative space. Therefore, I don't believe flex-shrink is having any effect on your layout.
flex-grow is consuming the positive free space and seems to be working fine.
You would need to set a flex-basis or add content to the items to put flex-shrink in play.
https://www.w3.org/TR/css-flexbox-1/#flex-property
This is related to float calculations. Your flex code is working perfectly fine, the problem arises from the arithmetic operation, where the width of the container might not perfectly divide to 3, so the result will be a floating number which might or not be rounded to the closest number, so that's why width of your first flexbox item might not be equal to width / 3 because of that rounding.
Tested with Chrome Inspector.
Take a look at https://css-tricks.com/snippets/css/a-guide-to-flexbox/#article-header-id-13
They suggest using the shorthand flex: [number]; because it intelligently sets the default flex-shrink to 0. Just because the default for flex-shrink is 1 doesn't mean that 1 is what you want. I haven't been using flexbox that long, but I've yet to come across a scenario in which I've had to specify a flex-shrink. 0 has been working for me thus far. Maybe somebody else can provide a scenario for using it.
TLDR
Use flex attribute instead of flex-grow

How to prevent a flex item from shrinking smaller than its content?

I've set up a jsfiddle to demonstrate the problem here:
http://jsfiddle.net/x0eo3aeo/2/
HTML:
<div class="flexContainer">
<div class="flexCol1">aaa</div>
<div class="flexCol2"><div style="width:100px; background-color:yellow;">bbb</div></div>
<div class="flexCol3"><div style="width:250px; background-color:pink;">Hello world, some long text here to make this element stay at 250px while splitting onto multiple lines.</div></div>
</div>
CSS:
.flexContainer {
display: flex;
width: 100%;
flex-direction: row;
}
.flexCol1, .flexCol3 {
flex: 1;
background-color: green;
}
Firefox actually behaves exactly how I want. Columns 1 and 3 flex equally until the width of column 3 hits the fixed size of its child div, and then only column 1 is flexed. However, in Chrome, both columns continue to flex equally and the child content of column 3 overflows.
Is there a way to achieve the Firefox-style behaviour in a cross-browser way?
You should be able to achieve the Firefox behavior in Chrome by adding min-width: -webkit-min-content; to .flexCol3. This prevents it from shrinking below its min-content width. (This is what's supposed to happen by default, due to min-width:auto introduced in the flexbox spec, but that hasn't been implemented in Chrome yet.)
As noted in comments below, IE doesn't seem to have a min-content width keyword implemented, so you might have to do something hackier there (like min-width: 250px). Fortunately, IE's next release (12?) does have min-width:auto implemented, so this should Just Work like Firefox there, I'm told.