A new value of the display property has landed in Chrome Canary and Firefox Nightlies. In the Editor’s Draft of the CSS Display Module Level 3, display: flow-root is defined as:
“The element generates a block container box, and lays out its contents using flow layout. It always establishes a new block formatting context for its contents.”
The key use of this comes when you have a box with a floated element inside it, and the floated element is taller than the other content inside the box. Default behaviour is that the box will not clear the float, and anything that comes afterwards will also wrap the floated item.
The floated element is out of flow causing the box to collapse.
The typical way we have solved this issue is to use a clearfix hack. The hack inserts some generated content, sets it to display; table or display: block and then clears it. This then ensures that the box becomes self-clearing, in our example the border will display after the floated item, and any following content will not rise up to wrap the float.
Enter display: flow-root
Using display: flow-root on an element will perform this clearing for us. Instead of needing to apply the clearfix hack we can use the CSS display property on the container with a value of flow-root.
.container {
display: flow-root;
}The border then clears the float and following content displays after our contained floated element.
After setting display: flow-root on the container
You can see a set of demos on CodePen. You will need to use Chrome Canary or Firefox Nightly to see this working today!
See the Pen display: flow-root by rachelandrew (@rachelandrew) on CodePen.
There is some discussion about the name of the value on an issue posted to the CSS Working Group GitHub. If you want to see interoperable support for this feature soon, then I’d suggest you pop over to the Edge UserVoice site and give it a vote.
31 Comments
I think “flow-root” is the new “clear: both”. So simple
This is excellent, and I can’t wait to for this to percolate through the browser ecosystem. I’ve been reliant on doing stuff like overflow: auto; on a parent element containing floating children or using inline-block elements. This will be a much cleaner way to resolve the problem.
This is a hack to mimic “display:flow-root”: http://codepen.io/thierry/pen/BpdBPy
PS: don’t do this at home
`display: flow-root` is in someway harmful (requires to add extra Element) till spec supports multiple values for “display” like `display: flex flow-root` (I haven’t jet proposed it to W3C) …
Otherwise, to cover cross-browser compatibility, can use:
“`
.clearfix:after {
content: “”;
display: block;
clear: both;
}
@supports (display: flow-root) {
.clearfix {
display: flow-root;
}
.clearfix:after {
display: none;
}
}
“`
Example http://codepen.io/laukstein/pen/WRENPz
@Binyamin I don’t think “clearfix” should be used as a fall back for “flow-root” because, unlike flow-root, clearfix does not create a new block formatting context. In my opinion, it is better to use the “overflow hack” (instead of clearfix) as it produces the same construct.
I forked a demo and modified it a bit to demonstrate some more differences in the behavior of clearfix-like and BFC-based solutions (including display:flow-root): http://codepen.io/SelenIT/pen/ggRVbG/ I also added one more hack to create the new BFC (at least, in the modern browsers).
Binyamin, per current spec, display:flow-root is a shorthand for display:block flow-root, so browsers won’t have problems with it. What is the expected result of display:flex flow-root, given that both ‘flex’ and ‘flow-root’ keywords control the inner layout of the element? And why does it require an extra element?
Hi Rachel
How about min-height: contain-floats?
Just open the proposal https://github.com/w3c/csswg-drafts/issues/983, hope will fix the harmful approach of “display” property.
@Mojtaba, it is probably changed to “min-height: min-content”, https://drafts.csswg.org/css-box/#min-max
@Ilya, as far as I know spec doesn’t support multiple values for “display”. For “flex-flow: column” you will need “display: flex” what means the extra Element. And if you have thousands such DOM elements, it will impact the performance.
“min-height: min-content” perhaps would be the best approach for spec.
“display:flex flow-root” is invalid. You can only have one inner display type. (Block is not an inner display type, it’s an outer display type.)
Would go for display: clear-after;
I always just use display: table on the containing element that does the trick.
display: table example:
http://codepen.io/jakobud/pen/JEywNY
Why can’t we simply improve support for flex boxes instead?
Por qué se sigue usando float: en css?
Flexbox ya está aceptado por todos los navegadores.
This is great news!
I feel like I completely stopped using floats after flexbox.
Great New 🙂
the problem with this fix can be seen with a simple jQuery command, $(‘.elem’).hide(); $(‘.elem’).show(); now, instead of my element being display:flow-root, it will revert to display:block (in theory)
Why not just assign “overflow: auto;” to the container div?
http://codepen.io/anon/pen/wgrJGr
http://codepen.io/anon/pen/wgrJGr
You could just use
overflow: hidden;
on the container, and you don’t need anything more fancy. No clearfix, no nothing.
I’ve always used overflow:hidden on containers to make them self-clearing. Gives the same results as this new property..
Maybe a separate property: “display-flow: root”
Please ignore my earlier comments about harmful flow-root. I missed the spec of ‘formatting context’, what makes “display: flow-root” reasonable.
Shortly … “display: flow-root” is relevant only for block, inline and list-item elements (others don’t need ‘clearfix’) and acts as “block” container.
I must be one of the only people using the css-tricks solution of group?
https://css-tricks.com/snippets/css/clear-fix/
[See update for august 2012.]
The main downside i can see for display:flow-root is that of backwards compatibility. Maybe in 3 years or so when it becomes actually embedded into the spec, it will need to have a fall back of some sort, and a simple
.group:after {
content: “”;
display: table;
clear: both;
}
works perfectly fine for the time being 🙂
When reading articles like this, I always wonder why the overflow:auto solution is so uncommon, even though it comes with no extra hassle – except for extra long non-breaking words maybe.
It is nice!
But only when your block is display: static.
Otherwise it is better to use clearfix.
@Mark Entingh, that is jQuery’s problem, not flow-root’s
Why, oh, why, did anyone think the default behavior for a container with floated content should be to not wrap? And it makes no sense that the solution ‘overflow: hidden;’ on the container would do anything but clip the not-wrapped content; perhaps that’s why it doesn’t always work.
A container that is set to ‘display: inline’ but which has floated content that needs to be wrapped, cannot be set to ‘display: flow-root’ without it becoming a block-flowed element. In that case you’d need to create another non-semantic container inside that inline container: so how is that better than clearfix?
flow-root…such a clear and descriptive property…it’s flow and root! barf
overflow: auto usually does the trick for me, and doesn’t have any of the issues of overflow: hidden (this is actually the first I’ve ever heard of anyone using overflow: hidden for clearing floats).