“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.

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.

@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?

@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.

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)

yves
on the 26 Jan 2017:

Why not just assign “overflow: auto;” to the container div?

http://codepen.io/anon/pen/wgrJGr

yves
on the 26 Jan 2017:

http://codepen.io/anon/pen/wgrJGr

Peter Galiba
on the 26 Jan 2017:

You could just use
overflow: hidden;
on the container, and you don’t need anything more fancy. No clearfix, no nothing.

joakim
on the 26 Jan 2017:

I’ve always used overflow:hidden on containers to make them self-clearing. Gives the same results as this new property..

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.

George
on the 30 Jan 2017:

It is nice!
But only when your block is display: static.
Otherwise it is better to use clearfix.

ivan
on the 31 Jan 2017:

@Mark Entingh, that is jQuery’s problem, not flow-root’s

Andre
on the 01 Feb 2017:

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?

Vince
on the 08 Feb 2017:

flow-root…such a clear and descriptive property…it’s flow and root! barf

Jason
on the 21 Feb 2017:

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).

Posted a response? Enter the URL

This site uses Webmention. If you post a response to this post on your own site, and you also support Webmention I'll be notified automatically. If not you can add a link here.

Article URL

Contact me

I am @rachelandrew on Twitter, and most other places online. You can email me at me@rachelandrew.co.uk.

I would love for you to check out my products Perch and Perch Runway, if you need a CMS for your site and care about your mark-up and site performance.