Mobile version (Display Regular Site)

Skip to: Navigation | Content | Sidebar | Footer


Weblog Entry

Clearance

March 03, 2005

A new solution just popped up that enables clearing of floats without the markup hacks of old. Great! Except there’s a caveat: scrollbars.

First reported on this SitePoint blog entry, later followed up with a description and some test cases by Anne van Kesteren, a new method of clearing floats involves using overflow: auto; to expand the parent and contain all children, thus forcing it to contain even floated elements within.

While overflow: auto is working for us in this case when it comes to vertical overflow, unfortunately it also applies to horizontal overflow as well. Therefore, all child elements must be smaller than or equal to the width of the parent, otherwise ugliness occurs.

Some examples are in order. First, here’s our basic setup:

We have two pargraphs side by side, contained within a parent div. We want the border of the div to surround both paragraphs; because they’re floated, though, the border of the parent doesn’t surround either and bunches up at the top as a solid grey bar.

There are now two methods to force the parent to expand and include the children; traditionally, you could have applied a float: left; to the parent and found some way to work around the resulting float. Or now with the new method, you don’t have to worry about any re-positioning of the parent after all, because the overflow property doesn’t affect it the way a float would:

(Note that due to positioning in these examples, the floated parent layout issues aren’t apparent; it would take extra complexity to demonstrate that, but if you’re at all familiar with floats it shouldn’t be too much of a stretch to see how the floated parent would be problematic.)

What happens, though, if the child element is simply too large for the parent? This may be triggered in environments where dynamic content might see the addition of an image with particularly large dimensions, or by something silly like the italicized text problem in Win/IE.

  • Example 4float parent with extra-wide child.
  • Example 5overflow parent with extra-wide child.

Ah. And so we reach the crux of the matter. Neither solution is perfect, they both have the same problem with horizontal overflow. Each handles it in a different way. The overflow method doesn’t require extra positioning aerobics to adapt to the position of a floated parent, but its method of handling overflow may be more problematic than the float method.

It’s always great to have another tool in the arsenal, but remember that the Achilles’ heel of this one is the horizontal scrollbars you may experience in your layout.


1
March 03, 01h

Yeah, I just started using overflow:auto, and I’ve found it to be kinda hit-and-miss. For example, I was just working with a simple header, left-nav, content layout, where the nav was floated left and the content had a left margin to cover it. In that case, adding overflow:auto caused Firefox to calculate the margin starting from the right side of the nav instead of the right side of the page all of a sudden, but IE still calculated it from the right. Beyond that, it didn’t actually expand the container to fit the content in IE. So I suspect this is useful only in certain circumstances.

2
March 03, 01h

Yeah, I just started using overflow:auto, and I’ve found it to be kinda hit-and-miss. For example, I was just working with a simple header, left-nav, content layout, where the nav was floated left and the content had a left margin to cover it. In that case, adding overflow:auto caused Firefox to calculate the margin starting from the right side of the nav instead of the right side of the page all of a sudden, but IE still calculated it from the right. Beyond that, it didn’t actually expand the container to fit the content in IE. So I suspect this is useful only in certain circumstances.

3
AkaXakA says:
March 03, 01h

The examples are nice and dandy, but what’s wrong with the “21st century Method” as described on Position Is Everything? (http://www.positioniseverything.net/easyclearing.html)

I thought floats were solved! Because well, they work in a number of instances _very well_ (and cross browser, Woo Hoo!), but when they don’t…use Absolute & Relative positioning! There’s nothing dirty about it…when you know how to use them!

4
dan says:
March 03, 03h

AkaXakA, I’m guessing that the ’21st century method’ would be considered by some to be not semantically correct, in that it is not sufficient separation of content from presentation.

5
AkaXakA says:
March 03, 04h

Dan? Are you kidding?

It’s a tad more semantic than adding an extra div, as using a class to add a presentational value (that the block should clear both) is pretty much what CSS is meant to do, so I can’t really see what part of it is semantically incorrect.

And if you have to clear a lot of things a simple:
.wrapperOfCleared div:after { blah }
should suffice.

6
dan says:
March 03, 09h

Sorry AkaXakA, I must apologise; I misread the page that you linked to. The ’21st century method’ is indeed more semantic than adding an extra div.

7
russ says:
March 03, 10h

I also perfer this method
http://www.positioniseverything.net/easyclearing.html

overflow = bad news to me with those ugly scrollbars rear there head!

8
March 03, 10h

Personally, I like to use the common clearing of floats instead of the “overflow” method. With the first method, I can set a specified width and wrap words to new lines to stretch vertically. When the font is resized, usually words aren’t too long to break out of the width. If your designs are most efficient, that is elastic, then you won’t have this problem at all (provided you use the clearing method, instead of the overflow method).

9
March 03, 11h

When I first played around a bit with this method, I found that overflow:hidden was better. Most of the time the widest element is an image, and I think a cropped image is better than scrollbars at narrow window widths.

10
Renato says:
March 03, 11h

The float method has another advantage: it also prevents the IE/Win’s bug Three Pixel Text-Jog.
http://www.positioniseverything.net/explorer/threepxtest.html

11
Dustin says:
March 03, 11h

For some reason this got many hoorah’s at sitepoint (since it came from one of their own), but I really haven’t found its usefulness for what I’ve been doing.

It’s always just been simple enough to float a parent div, and clear my footer.

I mean, what would clear be for anyway. It’s used to clear float’s, so why not use it. It’s proper css and I’ve been doing things right the whole time, and what I do works.

Overflow:auto assumes certain widths will be coming into play. At least by floating the parent div you have a set box to work with.

Congrats for Paul on making a simple technique widely known, … still don’t think it’s the best. I must admit though, the guy is a genius. I’ve learned amany of css doodles from Paul.

12
March 03, 11h

Perhaps IE’s overflow-x and overflow-y propeties would be handy here? They’re non-standard, which is a shame, but it would be nice if they *were* standard…

13
ACJ says:
March 03, 11h

Stuart; overflow-x and overflow-y are in the current CSS3 Working Draft, and are supported by Mozilla.

14
Dan Wood says:
March 03, 12h

Hey, this looks familiar! :-)

15
Mike P. says:
March 03, 12h

From what I read in the comments on my site [1], this method isn’t very robust…

I have yet to see anyone post any ‘real-world’ test cases (nor have I done them myself ;-), but I suppose if we are really careful this could be used. That, however, could lead to using multiple methods to solve this, which seems a little ‘house-of-cards’ish, no?

[1] http://www.fiftyfoureleven.com/weblog/web-development/css/simple-clearing-of-floats#comments

16
dan says:
March 03, 12h

:) Cheers for this - I must say the overflow:auto solution is posibly the simplest and most accurate. I only discovered it myself a few weeks ago.

Its a shame that there isn’t a specific solution to this problem. The solutions provided are either workarounds or hacks.
But then I guess neither hacks nor workarounds are something new!

17
Adam says:
March 03, 12h

I think we’ve established that overflow will have problems when you start with sufficiently complex designs.

I suspect that this approach is better suited to handling content, rather than layout.

For instance, my form fields are designed to be two colums (as most people do it). I’ve marked up my forms as:

<div class=”field required”>
<label>Field 1</label>
<div class=”input”>
<input />
</div>
</div>
<div class=”field required”>
<label>Field 2</label>
<div class=”input”>
<label><input type=”radio” /> Option 1</lable>
<label><input type=”radio” /> Option 2</lable>
</div>
</div>

Now in this case i think it would be grossly inefficient to add <div class=”clear”> </div> or <br class=”clear” /> for every field.

Similarily, if you had a list that you wanted to style as two columns, it would make sense.

But for large scale layout, use the clear tags. It seems a little more robust and reliable to me. If some content renders a little wonky on some browsers, it less detrimental than if the overall layout is not stable between browsers.

In the end, its another tool for the utility belt.

18
Huck says:
March 04, 04h

I use overflow:hidden on my website (datatonia.com/ to keep images from sticking out below the div.

It works well, but since I use a liquid design, it could technically clip the image if the window got too small. Fortunately, the image is thin, so I think it’s a reasonable edge case. And the scrollbars would be really annoying.

19
Tom Hamshere says:
March 04, 04h

Setting overflow to hidden rather than auto seems to get around the scrollbar problem quite effectively. I haven’t found any drawbacks yet.

Note that this doesn’t seem to work in Opera 7.

20
Aegir says:
March 04, 09h

You could just set width: auto on the containing element of course…

21
mark rush says:
March 05, 03h

problem im having is placing 2 floated elements within a containing div (for example)n the floated elements and content look fine, but the containing div seems to snap up behind them to the depth of 1 linespacing, i have to then add another tag within the containing div after the floats that clear:both anyone know a work around email me?

22
Tom says:
March 05, 04h

It’s another helpful tool, I’ve used to to solve an issue where a floated image was poking out of the bottom of a container. Instead of using a min-height hack I could just allow the container to wrap around the float.

23
ross says:
March 06, 06h

My quick and dirty tests:

Don’t declare width of the parent DIV
Don’t declare overflow:auto

IE6 - won’t clear.
FF/Moz - won’t clear.

Do declare the width of the parent DIV
Don’t declare overflow:auto

IE6 - will clear.
FF/Moz - won’t clear.

Don’t declare the width of the parent DIV
Do declare overflow:auto

IE6 - won’t clear.
FF/Moz - will clear.

Do declare the width of the parent DIV
Do declare overflow:auto

IE6 - will clear.
FF/Moz - will clear.

So this appears to mean that you still need to clear some other way if you want to clear a float on both IE6 and FF/Moz without defining a width.

24
Susanna says:
March 10, 11h

Thanks for posting about this, Dave. It gave me yet another thing to try toward fixing my Wide Table Problem, even though it has nothing to do with floats: http://www.superflippy.net/temp/big_table_demo2.htm

I hadn’t thought of using overflow:auto. It doesn’t really fix the problem, but it’s a potential solution for cases where scrolling in the middle of the page wouldn’t confuse the users.

25
Martijn says:
March 17, 03h

display:table is also something you could use.

26
Dinshaw says:
November 03, 07h

If you add the height:100% (or width I think) then the overflow:auto works in ie 6.

27
Gregar says:
March 21, 14h

You are doing an amazing amount of work – it’s a huge undertaking to engineer and build something that works all the time, everytime. Every bump in the road you have means a smoother road for your customers. I am watching VERY close – a Stokemonkey equipped Xtracycle is likely to be my next car. Keep it up… jj

28
Ruckus says:
April 02, 13h

Perhaps IE’s overflow-x and overflow-y propeties would be handy here? They’re non-standard, which is a shame,

but it would be nice if they *were* standard.