I am attempting to use Flex-By-Default in the same manner as Facebook's CSS layout project. I am having some trouble when it comes to overriding the styles for display: inline-flex elements.
Per this jsfiddle:
The HTML, with two '.test-me' divs:
<body>
<h1>TEST</h1>
<div class="test-me">
I'm correctly displayed as inline-flex
</div>
<div>
<div class="test-me">
'Styles' shows inline-flex, but 'Computed' shows flex
</div>
</div>
</body>
Here is the styling:
.test-me {
display: inline-flex;
background-color: green;
border: 1px solid black;
margin: 6px;
}
div, span {
display: flex;
/* Commenting out flex-direction makes second test-me div display correctly */
flex-direction: column;
background-color: purple;
}
I am am slightly concerned this is a browser bug: in Chrome Developer Tools, 'Styles' shows 'inline-flex' winning (as it's from the more specific styling), but 'Computed' shows 'flex'.
Even though 'display: flex' is crossed out (since it's overridden by 'display: inline-block'), disabling the already crossed-out style fixes the issue.
Revised Answer
#BoltClock, in the comments, provides the relevant section in the spec covering this behavior.
Section 4. Flex
Items
The display value of a flex item is blockified: if the specified
display of an in-flow child of an element generating a flex
container is an inline-level value, it computes to its block-level
equivalent.
This means that in a scenario like the one described in the question, where a child of a flex container is given an inline-level value, the child computes to its block-level equivalent. In a nutshell, the flex item with display: inline-flex becomes display: flex.
Original Answer
I am am slightly concerned this is a browser bug: in Chrome Developer
Tools, 'Styles' shows 'inline-flex' winning (as it's from the more
specific styling), but 'Computed' shows 'flex'.
Tested your code in Chrome, Firefox and Internet Explorer 11. The behavior is all the same. So I wouldn't say this is a browser bug.
Although you are correct that in Chrome (and Firefox) the inspector shows 'Styles' having inline-flex and 'Computed' having flex, in IE11 it shows inline-flex on both panes, but it renders like the others nonetheless.
A reading of the spec suggests that flex items can only be block elements. Even though you're applying display: inline-flex to the div, the same div is a flex item of a larger container with display: flex. The flex item with inline-flex is possibly being overridden as part of the flex formatting context.
Although there is no direct reference to the spec, here's another answer that may be helpful: https://stackoverflow.com/a/27090088/3597276
Related
I'm trying to center inner elements of a <button>-tag with flexbox's justify-content: center. But Safari does not center them. I can apply the same style to any other tags and it works as intended (see the <p>-tag). Only the button is left-aligned.
Try Firefox or Chrome and you can see the difference.
Is there any user agent style I have to overwrite? Or any other solution to this problem?
div {
display: flex;
flex-direction: column;
width: 100%;
}
button, p {
display: flex;
flex-direction: row;
justify-content: center;
}
<div>
<button>
<span>Test</span>
<span>Test</span>
</button>
<p>
<span>Test</span>
<span>Test</span>
</p>
</div>
And a jsfiddle:
http://jsfiddle.net/z3sfwtn2/2/
The Problem
In some browsers the <button> element doesn't accept changes to its display value, beyond switching between block and inline-block. This means that a <button> element cannot be a flex or grid container, or a <table>, either.
In addition to <button> elements, you may find this constraint applying to <fieldset> and <legend> elements, as well.
See the bug reports below for more details.
Note: Although they cannot be flex containers, <button> elements can be flex items.
The Solution
There is a simple and easy cross-browser workaround to this problem:
Wrap the content of the button in a span, and make the span the flex container.
Adjusted HTML (wrapped button content in a span)
<div>
<button>
<span><!-- using a div also works but is not valid HTML -->
<span>Test</span>
<span>Test</span>
</span>
</button>
<p>
<span>Test</span>
<span>Test</span>
</p>
</div>
Adjusted CSS (targeted span)
button > span, p {
display: flex;
flex-direction: row;
justify-content: center;
}
Revised Demo
References / Bug Reports
Flexbox on a <button> blockifies the contents but doesn't establish a flex formatting context
User (Oriol Brufau): The children of the <button> are blockified, as dictates the flexbox spec. However, the <button> seems to establish a block formatting context instead of a flex one.
User (Daniel Holbert): That is effectively what the HTML spec requires. Several HTML container-elements are "special" and effectively ignore their CSS display value in Gecko [aside from whether it's inline-level vs. block-level]. <button> is one of these. <fieldset> & <legend> are as well.
Add support for display:flex/grid and columnset layout inside <button> elements
User (Daniel Holbert):
<button> is not implementable (by browsers) in pure CSS, so they are a bit of a black box, from the perspective of CSS. This means that
they don't necessarily react in the same way that e.g. a <div>
would.
This isn't specific to flexbox -- e.g. we don't render scrollbars if you put overflow:scroll on a button, and we don't render it as a
table if you put display:table on it.
Stepping back even further, this isn't specific to <button>. Consider <fieldset> and <table> which also have special rendering
behavior.
And old-timey HTML elements like <button> and <table> and <fieldset> simply do not support custom display values, other than
for the purposes of answering the very high-level question of "is this
element block-level or inline-level", for flowing other content around
the element.
Also see:
Flexbug #9: Some HTML elements can't be flex containers
10. Some HTML elements can't be grid containers
Here is my simplest hack.
button::before,
button::after {
content: '';
flex: 1 0 auto;
}
Starting Chrome 83, the button now works as inline-grid/grid/inline-flex/flex.
Here is a snippet (for those using Chrome 83 and up):
button {
display: inline-flex;
height: 2rem;
align-items: flex-end;
width: 4rem;
-webkit-appearance: none;
justify-content: flex-end;
}
<!--
The align-items keyword should fail in Chrome 81 or earlier, but work in Chrome 83 or later. To see the error, the button needs styles that make it more of an extrinsic container. In other words, it needs a height or width set.
-->
<button>Hi</button>
<input type="button" value="Hi">
I'm trying to center inner elements of a <button>-tag with flexbox's justify-content: center. But Safari does not center them. I can apply the same style to any other tags and it works as intended (see the <p>-tag). Only the button is left-aligned.
Try Firefox or Chrome and you can see the difference.
Is there any user agent style I have to overwrite? Or any other solution to this problem?
div {
display: flex;
flex-direction: column;
width: 100%;
}
button, p {
display: flex;
flex-direction: row;
justify-content: center;
}
<div>
<button>
<span>Test</span>
<span>Test</span>
</button>
<p>
<span>Test</span>
<span>Test</span>
</p>
</div>
And a jsfiddle:
http://jsfiddle.net/z3sfwtn2/2/
The Problem
In some browsers the <button> element doesn't accept changes to its display value, beyond switching between block and inline-block. This means that a <button> element cannot be a flex or grid container, or a <table>, either.
In addition to <button> elements, you may find this constraint applying to <fieldset> and <legend> elements, as well.
See the bug reports below for more details.
Note: Although they cannot be flex containers, <button> elements can be flex items.
The Solution
There is a simple and easy cross-browser workaround to this problem:
Wrap the content of the button in a span, and make the span the flex container.
Adjusted HTML (wrapped button content in a span)
<div>
<button>
<span><!-- using a div also works but is not valid HTML -->
<span>Test</span>
<span>Test</span>
</span>
</button>
<p>
<span>Test</span>
<span>Test</span>
</p>
</div>
Adjusted CSS (targeted span)
button > span, p {
display: flex;
flex-direction: row;
justify-content: center;
}
Revised Demo
References / Bug Reports
Flexbox on a <button> blockifies the contents but doesn't establish a flex formatting context
User (Oriol Brufau): The children of the <button> are blockified, as dictates the flexbox spec. However, the <button> seems to establish a block formatting context instead of a flex one.
User (Daniel Holbert): That is effectively what the HTML spec requires. Several HTML container-elements are "special" and effectively ignore their CSS display value in Gecko [aside from whether it's inline-level vs. block-level]. <button> is one of these. <fieldset> & <legend> are as well.
Add support for display:flex/grid and columnset layout inside <button> elements
User (Daniel Holbert):
<button> is not implementable (by browsers) in pure CSS, so they are a bit of a black box, from the perspective of CSS. This means that
they don't necessarily react in the same way that e.g. a <div>
would.
This isn't specific to flexbox -- e.g. we don't render scrollbars if you put overflow:scroll on a button, and we don't render it as a
table if you put display:table on it.
Stepping back even further, this isn't specific to <button>. Consider <fieldset> and <table> which also have special rendering
behavior.
And old-timey HTML elements like <button> and <table> and <fieldset> simply do not support custom display values, other than
for the purposes of answering the very high-level question of "is this
element block-level or inline-level", for flowing other content around
the element.
Also see:
Flexbug #9: Some HTML elements can't be flex containers
10. Some HTML elements can't be grid containers
Here is my simplest hack.
button::before,
button::after {
content: '';
flex: 1 0 auto;
}
Starting Chrome 83, the button now works as inline-grid/grid/inline-flex/flex.
Here is a snippet (for those using Chrome 83 and up):
button {
display: inline-flex;
height: 2rem;
align-items: flex-end;
width: 4rem;
-webkit-appearance: none;
justify-content: flex-end;
}
<!--
The align-items keyword should fail in Chrome 81 or earlier, but work in Chrome 83 or later. To see the error, the button needs styles that make it more of an extrinsic container. In other words, it needs a height or width set.
-->
<button>Hi</button>
<input type="button" value="Hi">
I am trying to vertically align elements within an ID wrapper. I gave the property display:inline-flex; to this ID as the ID wrapper is the flex container.
But there is no difference in presentation. I expected that everything in the wrapper ID would be displayed inline. Why isn't it?
#wrapper {
display: inline-flex;
/*no difference to display:flex; */
}
<body>
<div id="wrapper">
<header>header</header>
<nav>nav</nav>
<aside>aside</aside>
<main>main</main>
<footer>footer</footer>
</div>
</body>
display: inline-flex does not make flex items display inline. It makes the flex container display inline. That is the only difference between display: inline-flex and display: flex. A similar comparison can be made between display: inline-block and display: block, and pretty much any other display type that has an inline counterpart.1
There is absolutely no difference in the effect on flex items; flex layout is identical whether the flex container is block-level or inline-level. In particular, the flex items themselves always behave like block-level boxes (although they do have some properties of inline-blocks). You cannot display flex items inline; otherwise you don't actually have a flex layout.
It is not clear what exactly you mean by "vertically align" or why exactly you want to display the contents inline, but I suspect that flexbox is not the right tool for whatever you are trying to accomplish. Chances are what you're looking for is just plain old inline layout (display: inline and/or display: inline-block), for which flexbox is not a replacement; flexbox is not the universal layout solution that everyone claims it is (I'm stating this because the misconception is probably why you're considering flexbox in the first place).
1 The differences between block layout and inline layout are outside the scope of this question, but the one that stands out the most is auto width: block-level boxes stretch horizontally to fill their containing block, whereas inline-level boxes shrink to fit their contents. In fact, it is for this reason alone you will almost never use display: inline-flex unless you have a very good reason to display your flex container inline.
OK, I know at first might be a bit confusing, but display is talking about the parent element, so means when we say: display: flex;, it's about the element and when we say display:inline-flex;, is also making the element itself inline...
It's like make a div inline or block, run the snippet below and you can see how display flex breaks down to next line:
.inline-flex {
display: inline-flex;
}
.flex {
display: flex;
}
p {
color: red;
}
<body>
<p>Display Inline Flex</p>
<div class="inline-flex">
<header>header</header>
<nav>nav</nav>
<aside>aside</aside>
<main>main</main>
<footer>footer</footer>
</div>
<div class="inline-flex">
<header>header</header>
<nav>nav</nav>
<aside>aside</aside>
<main>main</main>
<footer>footer</footer>
</div>
<p>Display Flex</p>
<div class="flex">
<header>header</header>
<nav>nav</nav>
<aside>aside</aside>
<main>main</main>
<footer>footer</footer>
</div>
<div class="flex">
<header>header</header>
<nav>nav</nav>
<aside>aside</aside>
<main>main</main>
<footer>footer</footer>
</div>
</body>
Also quickly create the image below to show the difference at a glance:
flex and inline-flex both apply flex layout to children of the container. Container with display:flex behaves like a block-level element itself, while display:inline-flex makes the container behaves like an inline element.
Using two-value display syntax instead, for clarity
The display CSS property in fact sets two things at once: the outer display type, and the inner display type. The outer display type affects how the element (which acts as a container) is displayed in its context. The inner display type affects how the children of the element (or the children of the container) are laid out.
If you use the two-value display syntax, which is only supported in some browsers like Firefox, the difference between the two is much more obvious:
display: block is equivalent to display: block flow
display: inline is equivalent to display: inline flow
display: flex is equivalent to display: block flex
display: inline-flex is equivalent to display: inline flex
display: grid is equivalent to display: block grid
display: inline-grid is equivalent to display: inline grid
Outer display type: block or inline:
An element with the outer display type of block will take up the whole width available to it, like <div> does. An element with the outer display type of inline will only take up the width that it needs, with wrapping, like <span> does.
Inner display type: flow, flex or grid:
The inner display type flow is the default inner display type when flex or grid is not specified. It is the way of laying out children elements that we are used to in a <p> for instance. flex and grid are new ways of laying out children that each deserve their own post.
Conclusion:
The difference between display: flex and display: inline-flex is the outer display type, the first's outer display type is block, and the second's outer display type is inline. Both of them have the inner display type of flex.
References:
The two-value syntax of the CSS Display property on mozzilla.org
The Difference between "flex" and "inline-flex"
Short answer:
One is inline and the other basically responds like a block element(but has some of it's own differences).
Longer answer:
Inline-Flex - The inline version of flex allows the element, and it's children, to have flex properties while still remaining in the regular flow of the document/webpage. Basically, you can place two inline flex containers in the same row, if the widths were small enough, without any excess styling to allow them to exist in the same row. This is pretty similar to "inline-block."
Flex - The container and it's children have flex properties but the container reserves the row, as it is taken out of the normal flow of the document. It responds like a block element, in terms of document flow. Two flexbox containers could not exist on the same row without excess styling.
The problem you may be having
Due to the elements you listed in your example, though I am guessing, I think you want to use flex to display the elements listed in an even row-by-row fashion but continue to see the elements side-by-side.
The reason you are likely having issues is because flex and inline-flex have the default "flex-direction" property set to "row." This will display the children side-by side. Changing this property to "column" will allow your elements to stack and reserve space(width) equal to the width of its parent.
Below are some examples to show how flex vs inline-flex works and also a quick demo of how inline vs block elements work...
display: inline-flex; flex-direction: row;
Fiddle
display: flex; flex-direction: row;
Fiddle
display: inline-flex; flex-direction: column;
Fiddle
display: flex; flex-direction: column;
Fiddle
display: inline;
Fiddle
display: block
Fiddle
Also, a great reference doc:
A Complete Guide to Flexbox - css tricks
Display:flex apply flex layout to the flex items or children of the container only. So, the container itself stays a block level element and thus takes up the entire width of the screen.
This causes every flex container to move to a new line on the screen.
Display:inline-flex apply flex layout to the flex items or children as well as to the container itself. As a result the container behaves as an inline flex element just like the children do and thus takes up the width required by its items/children only and not the entire width of the screen.
This causes two or more flex containers one after another, displayed as inline-flex, align themselves side by side on the screen until the whole width of the screen is taken.
I'd like to add some details about screen reader behaviour, because there's some surprises here.
Some background first. Some screen readers like NVDA handle display: block and display: inline-block differently (and they should, as you will see later).
Comparison between different display attributes
display: block
A display: block element will always be announced in a separate "line", meaning NVDA will stop talking after its contents, and the user will manually tell NVDA to announce the next element (typically with Down arrow key).
<div>This is the first line</div>
<div>This is another line</div>
This will make NVDA announce This is the first line, and then This is another line.
The following yields the same result:
<span style="display: block">This is the first line</span>
<span style="display: block">This is another line</span>
display: inline-block
A display: inline-block element will be announced together with all preceding and following other inline elements (display: inline and display: inline-block).
<span style="display: inline-block">This is the first line</span>
<span style="display: inline-block">This is another line</span>
This will make the screen reader announce both elements in one go: This is the first line This is another line.
As said before, it doesn't matter whether it's an inline or inline-block element; the following yields the exact same result:
<span style="display: inline">This is the first line</span> <!-- Inline! -->
<span style="display: inline-block">This is another line</span> <!-- Inline block! -->
display: flex
This works exactly like display: block.
display: inline-flex
Surprisingly, this also works like display: block, not like display: inline-block!
display: grid / display: inline-grid
I didn't test this, but I expect the same like with flex / inline-flex here.
Why is that a problem?
Using display: inline-block, one can create elements that visually look very distinct, but semantically are treated "as one".
For example, consider the following headline in an online news platform:
<h2>
<span class="category">Rain forests</span>
They need our love
</h2>
You now want to visually style the category (Rain forests) very different to the "real" title ('They need our love'), i.e. by putting each in its own line, something like this:
If you'd make category a display: block element, then the screen reader would announce the heading in two separate lines like this: Rain forests, heading level 2, then They need our love, heading level 2. This is confusing to the user: are there two different headings on the page? Why is there no content for the first one (instead, immediately an apparent second heading seems to follow)?
If however you'd make category a display: inline-block element, then the screen reader would announce the heading in one go: Rain forests They need our love, heading level 2.
It is sad, that display: inline-flex (and probably inline-grid, too) does not mimic the behaviour. So if you want to offer perfect accessibility, you might want to use inline-block in such situations.
You can display flex items inline, providing your assumption is based on wanting flexible inline items in the 1st place. Using flex implies a flexible block level element.
The simplest approach is to use a flex container with its children set to a flex property. In terms of code this looks like this:
.parent{
display: inline-flex;
}
.children{
flex: 1;
}
flex: 1 denotes a ratio, similar to percentages of a element's width.
Check these two links in order to see simple live Flexbox examples:
https://njbenjamin.com/bundle-3.htm
https://njbenjamin.com/bundle-4.htm
If you use the 1st example:
https://njbenjamin.com/flex/index_1.htm
You can play around with your browser console, to change the display of the container element between flex and inline-flex.
You need a bit more information so that the browser knows what you want. For instance, the children of the container need to be told "how" to flex.
Updated Fiddle
I've added #wrapper > * { flex: 1; margin: auto; } to your CSS and changed inline-flex to flex, and you can see how the elements now space themselves out evenly on the page.
Open in Full page for better understanding
.item {
width : 100px;
height : 100px;
margin: 20px;
border: 1px solid blue;
background-color: yellow;
text-align: center;
line-height: 99px;
}
.flex-con {
flex-wrap: wrap;
/* <A> */
display: flex;
/* 1. uncomment below 2 lines by commenting above 1 line */
/* <B> */
/* display: inline-flex; */
}
.label {
padding-bottom: 20px;
}
.flex-inline-play {
padding: 20px;
border: 1px dashed green;
/* <C> */
width: 1000px;
/* <D> */
display: flex;
}
<figure>
<blockquote>
<h1>Flex vs inline-flex</h1>
<cite>This pen is understand difference between
flex and inline-flex. Follow along to understand this basic property of css</cite>
<ul>
<li>Follow #1 in CSS:
<ul>
<li>Comment <code>display: flex</code></li>
<li>Un-comment <code>display: inline-flex</code></li>
</ul>
</li>
<li>
Hope you would have understood till now. This is very similar to situation of `inline-block` vs `block`. Lets go beyond and understand usecase to apply learning. Now lets play with combinations of A, B, C & D by un-commenting only as instructed:
<ul>
<li>A with D -- does this do same job as <code>display: inline-flex</code>. Umm, you may be right, but not its doesnt do always, keep going !</li>
<li>A with C</li>
<li>A with C & D -- Something wrong ? Keep going !</li>
<li>B with C</li>
<li>B with C & D -- Still same ? Did you learn something ? inline-flex is useful if you have space to occupy in parent of 2 flexboxes <code>.flex-con</code>. That's the only usecase</li>
</ul>
</li>
</ul>
</blockquote>
</figure>
<br/>
<div class="label">Playground:</div>
<div class="flex-inline-play">
<div class="flex-con">
<div class="item">1</div>
<div class="item">2</div>
<div class="item">3</div>
<div class="item">4</div>
</div>
<div class="flex-con">
<div class="item">X</div>
<div class="item">Y</div>
<div class="item">Z</div>
<div class="item">V</div>
<div class="item">W</div>
</div>
</div>
I'm trying to center inner elements of a <button>-tag with flexbox's justify-content: center. But Safari does not center them. I can apply the same style to any other tags and it works as intended (see the <p>-tag). Only the button is left-aligned.
Try Firefox or Chrome and you can see the difference.
Is there any user agent style I have to overwrite? Or any other solution to this problem?
div {
display: flex;
flex-direction: column;
width: 100%;
}
button, p {
display: flex;
flex-direction: row;
justify-content: center;
}
<div>
<button>
<span>Test</span>
<span>Test</span>
</button>
<p>
<span>Test</span>
<span>Test</span>
</p>
</div>
And a jsfiddle:
http://jsfiddle.net/z3sfwtn2/2/
The Problem
In some browsers the <button> element doesn't accept changes to its display value, beyond switching between block and inline-block. This means that a <button> element cannot be a flex or grid container, or a <table>, either.
In addition to <button> elements, you may find this constraint applying to <fieldset> and <legend> elements, as well.
See the bug reports below for more details.
Note: Although they cannot be flex containers, <button> elements can be flex items.
The Solution
There is a simple and easy cross-browser workaround to this problem:
Wrap the content of the button in a span, and make the span the flex container.
Adjusted HTML (wrapped button content in a span)
<div>
<button>
<span><!-- using a div also works but is not valid HTML -->
<span>Test</span>
<span>Test</span>
</span>
</button>
<p>
<span>Test</span>
<span>Test</span>
</p>
</div>
Adjusted CSS (targeted span)
button > span, p {
display: flex;
flex-direction: row;
justify-content: center;
}
Revised Demo
References / Bug Reports
Flexbox on a <button> blockifies the contents but doesn't establish a flex formatting context
User (Oriol Brufau): The children of the <button> are blockified, as dictates the flexbox spec. However, the <button> seems to establish a block formatting context instead of a flex one.
User (Daniel Holbert): That is effectively what the HTML spec requires. Several HTML container-elements are "special" and effectively ignore their CSS display value in Gecko [aside from whether it's inline-level vs. block-level]. <button> is one of these. <fieldset> & <legend> are as well.
Add support for display:flex/grid and columnset layout inside <button> elements
User (Daniel Holbert):
<button> is not implementable (by browsers) in pure CSS, so they are a bit of a black box, from the perspective of CSS. This means that
they don't necessarily react in the same way that e.g. a <div>
would.
This isn't specific to flexbox -- e.g. we don't render scrollbars if you put overflow:scroll on a button, and we don't render it as a
table if you put display:table on it.
Stepping back even further, this isn't specific to <button>. Consider <fieldset> and <table> which also have special rendering
behavior.
And old-timey HTML elements like <button> and <table> and <fieldset> simply do not support custom display values, other than
for the purposes of answering the very high-level question of "is this
element block-level or inline-level", for flowing other content around
the element.
Also see:
Flexbug #9: Some HTML elements can't be flex containers
10. Some HTML elements can't be grid containers
Here is my simplest hack.
button::before,
button::after {
content: '';
flex: 1 0 auto;
}
Starting Chrome 83, the button now works as inline-grid/grid/inline-flex/flex.
Here is a snippet (for those using Chrome 83 and up):
button {
display: inline-flex;
height: 2rem;
align-items: flex-end;
width: 4rem;
-webkit-appearance: none;
justify-content: flex-end;
}
<!--
The align-items keyword should fail in Chrome 81 or earlier, but work in Chrome 83 or later. To see the error, the button needs styles that make it more of an extrinsic container. In other words, it needs a height or width set.
-->
<button>Hi</button>
<input type="button" value="Hi">
I've played with this nice CSS Flexbox demo page and I understand most of the concepts, however I was not able to see flex-shrink in work. Whatever settings I apply there, I see no difference on the page.
From the spec:
<‘flex-grow’>
This component sets ‘flex-grow’ longhand and specifies the
flex grow factor, which determines how much the flex item will grow
relative to the rest of the flex items in the flex container when
positive free space is distributed. When omitted, it is set to ‘1’.
<‘flex-shrink’>
This component sets ‘flex-shrink’ longhand and specifies the
flex shrink factor, which determines how much the flex item will
shrink relative to the rest of the flex items in the flex container
when negative free space is distributed. When omitted, it is set to
‘1’. The flex shrink factor is multiplied by the flex basis when
distributing negative space.
In what circumstances will flex-shrink be applied (i.e. when the negative space is distributed)? I've tried custom page with setting widths on the flexbox element and (min-)widths of the elements inside it to make an overflow, but it seems it's not the described case.
Is it supported at all already?
As a solution, either a set of options on the linked demo, or JSFiddle-like live demo will be highly appreciated.
In order to see flex-shrink in action, you need to be able to make its container smaller.
HTML:
<div class="container">
<div class="child one">
Child One
</div>
<div class="child two">
Child Two
</div>
</div>
CSS:
div {
border: 1px solid;
}
.container {
display: flex;
}
.child.one {
flex: 1 1 10em;
color: green;
}
.child.two {
flex: 2 2 10em;
color: purple;
}
http://jsfiddle.net/GyXxT/ (unprefixed -- Opera or Firefox nightly build)
http://jsfiddle.net/GyXxT/1/ (webkit)
In this example, both child elements ideally want to be 10em wide. If the parent element is greater than 20em wide, the 2nd child will take twice as much leftover space as the 1st child, making it appear bigger. If the parent element is less than 20em wide, then the 2nd child will have twice as much shaved off of it as the 1st child, making it look smaller.
Current flexbox support: Opera (unprefixed), Chrome (prefixed), IE10 (prefixed, but uses slightly different property names/values). Firefox currently uses the old spec from 2009 (prefixed), but the new spec is supposed to be available in experimental builds right now (unprefixed).