Calling all Gurus! Which Clearfix is best? .clearfix - not clearing method!

[Paul O'B]

Straight from Web Standards Creativity with some class name changes. Its the one I prefer.

.encapsulate:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}

/* IE7 still a ******* */
*+html .encapsulate:after {
    display: inline-block;
    display: block;
}

/* trigger hasLayout in <=IE6 \*/
* html .encapsulate {
       height: 1&#37;;
}
/* end trigger */

Either you have copied it incorrectly or the original is flawed but the example above will not work in IE7 for reasons I have already mentioned.

First of all IE7 has no support for the pseudo element :after so the IE7 hacks you added (*+html) will do nothing at all.

If you meant to write it without the :after element like this instead:

/* IE7 still a ******* */
*+html .encapsulate {
display: inline-block;
display: block;
}

Then it still won't work for the issues I mentioned and linked to in suzy's article above.

For the method to work properly it would need to look like this;

.encapsulate:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}

/* IE7 still a ******* */
*+html .encapsulate {
    display: inline-block;
}
*+html .encapsulate {
    display: block;
}
/* trigger hasLayout in <=IE6 \*/
* html .encapsulate {
       height: 1%;
}
/* end trigger */

Which in the end is a total waste of time from the original version as you have simply added more hacks into the mix and made it longer than before

I don't see any need to change the name from .clearfix as it is long established name now and everyone now knows what it means and therefore aids readability. It may have been the wrong choice originally but I see little point in changing it now.

[Suzy]

hey guys, interesting thread.. just came across it while looking for something else, so, sorry for the late input

What an ironic anomaly in this thread:
AnalogPanda tells the story of the great grandmother, and how we shouldn't always do things just because... to which I was tempted to reply that I am the GGM in that story having wrote about the use of :after as a "clearing fix" before it became known as that and also being the Suzy that realised what the inline-block/block switch could do!

I fully understand why/how it might now be being perceived as being named wrongly, however my argument to that is.. Do you still think the "voice family hack" is named wrongly, do you still use it, or has hindsight given you a different perspective?

Then AnalogPanda also says that no less than Dan Cederholm may be arguing the class name semantics of "clearfix" and I can't believe my little "old" ears, I'm with Paul.. why change it now, just let sleeping dogs lie and all that. Perhaps it's time some of us really explained.. (or perhaps we shouldn't, what would they discuss at the conferences then ) It is a shame that it, clearfix, actually became so mainstream, so much so that now people are actually debating changing the name instead of realising and teaching that the "fix" as it was conceived is NOT necessary any more.

as an aside: "clearfix" may not be such a bad name if only folks would realise what it *was* actually designed to achieve, as in a fix for clearing floats

the clearfix "hack" was designed to fill a void - the void being that all browsers quite rightly didn't know how to instruct a parent element to contain it's floated children, (as in the next element after set of floated columns, usually a footer, wouldn't clear the previous elements)

It was written to be that way in the recs/specs CSS2 and early CSS2.1, there was no CSS (semantic) way.. the purists could see that the interpretation of specs, by the UA's was right, but that this was an issue too big to be ignored and that it was the responsibility of the W3C to provide a more acceptable CR (candidate recommendation). At the same time realists needed to find a way to make it work meantime as the demand was already there and so use was made of property that has now brought with it other problems. The clever spec writers could see this coming and they quite rightly did not change the behaviour of the floats themselves, instead concentrating on getting the behaviour/support for overflow implemented. Then there was IE..

IE, as ever, did the job, but wrongly. As long as a width/height (or more correctly hasLayout) was set on the parent it worked, well it worked the way that most visual layout designers were used to.. however that only led to further misunderstanding of the situation, and possibly why the two questions now arise in the same thread? You may think IE was right but just read the side effects of hasLayout and then tell me you'd rather still be dealing with that in 10 years time! If it had not been discovered it might still be there and holding back the more compliant browsers

anyway I digress,
The old method of clearing floats was to put an empty element after the floats, but still inside the containing element, this made the containing element think it had some real content and so it stretched to contain it.. as long as that element, generated or otherwise, was empty (commonly referred to as a clearing div) then it was Job Done!

The CSS early adopters knew that that building a non-semantic empty element into your HTML required knowledge of the final outcome of the design, which is a basic flaw in the separation of content from presentation mantra and so the CSS clearfix hack was born, the hack gave us a way to generate that empty (last-child) element into the container without touching the HTML. The :after pseudo element is a way to generate content.

Now that :after element should only ever have been applied to the element that contains the floats, it is the floats as a group or set that require clearance and even with that understanding it should have been understood it was till a hack because it was either that or an empty HTML element.. both were liable to cause spacing issues or unexpected clearance if you didn't understand how float/clear works in general (note I see PIE has updated their easyclearing article to this effect and removed some of the older reasons why), so to see it now being used so widely I'm afraid makes me cringe, and this thread only adds that factor

anyway..At some point in time after the "clearfix" hack was born, the recs, or the understanding/implementation of them, changed, and the compliant browsers who were updating more regularly than IE changed the way they behaved WRT floats, and not even most of the good CSS people noticed (with the possible exception of Paul and his overflow discovery ) - elements with overflow (anything other than visible) and/or float set, themselves became able to contain floated children, albeit still buggy at the time of discovery

As soon as the overflow method became stable it negated the use of the .clearfix:after method completely, as it should, because the overuse was now causing it to run into other clearance issues (just read the Drupal forums!) whereby a cleared element will clear all previous floats IN THE SOURCE not just the ones you were likely attempting to clear. E.G. if you're using this in say a middle column and your left column is also floated then the :after will clear the left column too causing the ol' "float drop" issue.

Also, somewhere along the line the clearfix method became enmeshed, albeit unwittingly, with the IE error which is hasLayout and subsequently with 'my' TRIPswitch it appears, that was not intentional the hasLayout TRIPswitch was discovered independently of the easyclearing method it just happened to work well with it, especially once IE7 came out, as the ingredients were already present! - So we now need to separate the fact that:

1. IE was (and still is as of IE7) wrongly clearing the floats in the first place
2. The :after pseudo method was only to fill a void for the other browsers
3. :after never worked for IE, still doesn't
4. IE cleared the floats courtesy of its proprietary hasLayout behaviour, however it was triggered - IOW the second part of clearfix
5. IE7 now *seems* to support the correct behaviour of overflow, which should mean no hacks are necessary
6. re: #5 - it doesn't, overflow triggers hasLayout, but this behaviour is good enough for now, IE8 gets it right.. but it means the IE legacy part of the clearfix may still be needed for a while yet to take care of IE6
7. the inline-block/block part of the "easyclearing hack" (the tripswitch) is doing no more than than setting hasLayout for IE7 and below and it actually negates the use of the * html {height} hack

is that clear

simply put the :after part of the hack is No Longer necessary, all that might be required is to trigger hasLayout to true for IE7 and below, which you can do using the inline-block/block trip OR zoom:1, or height or or or in a conditional comment.

Let me try to explain the second bit of the clearfix seeing as how I hope you see the first part isn't necessary anymore (the only instance I found it necessary in the last 8 years was for NN6, which I presume no-one is supporting anymore)

The "inline-block" part of clearfix was born because of IE/Mac, it didn't like the method at all and needed display: inline-block; set (PIE originally documented as inline-table) but whatever.. and because it was thought only necessary for IE/Mac a Mac hiding rule was born in order to set the display property back to block for the other browsers only (i.e. everything except IE/Mac). Then the Holly Hack was added in order to trigger hasLayout for IE6 and below, and because the original conception of the entire hack used display:inline-table for IE/Mac as opposed to inline-block both parts were necessary.

Later discoveries about inline-block added to the dropping of support for IE/Mac meant it could be changed a lot..

Later discoveries about hasLayout revealed that the inline-block rule had a magical IE bullet.. you can, as explained in the links to my site above, trigger hasLayout for IE using the inline-block/block switch (for >=IE5.5) so if you use it you no longer need the Holly Hack as it is doing the same thing. AND probably the most misunderstood part of this whole thing is that no part of the switch needs hiding (**) so those complex *+html or html[xmlns] selectors are not needed! - (**) All this presumes of course that you are now no longer supporting IE/Mac, which was the only reason the "block" part of the rule was hidden in the first place

if ANY browser sees:

div {display: inline-block;}
div {display: block;}

what's it going to do?..
A: it will use the display: block - property: value because of the simple cascade.

IE will also use the "block" property for visual display purposes, HOWEVER, and, as long as the rules are in separate rulesets! it will also silently trigger it's own hasLayout property to true. display: inline-block; is a hasLayout setting property and the block does not overrule this, and because no other browser even knows what hasLayout is it's good to go!

So if that is setting hasLayout, which is IE's naughty method of containing floats, the height hack part is only a duplication of the inline-block/block hasLayout trigger.

Now the real updated version! (V5 browsers no longer supported)
The overflow property is now the recommended way to instruct a containing element to contain its floated children, IE7 is a good boy as far as this goes too so you could relegate the whole hasLayout trigger business to a [lte IE 6] conditional if you want and use whatever your favourite hasLayout trigger is... but you don't need to if you use the existing "tripswitch" trigger, as it is, and always should be, read safely by all browsers including IE

Perhaps all you need to be aware of for now, or for future understanding of what's going on in stylesheets you might be asked to deal with, the reason for this history lesson is.. New in IE7 is the fact that the overflow property triggers hasLayout=true too so that is why float containment is now "working" correctly in IE7 though I believe that they have managed to retain the correct behaviour in IE8 without hasLayout, which is good news going forward with this.

To have the inline-block/block switch in the same sheet as overflow is a duplication of the hasLayout trigger for IE7 only.. it does no harm to have the duplication for IE and it does no harm at all to other browsers too. But the knowledge of what it is might have a bearing on where you put your IE workaround. I think you can see that whether in a conditional or not, there is no longer any need for the hiding hacks or the IE parse hacks. Parse hacks, if used, should definitely go in a conditional comment as there is no telling what a new browser (any flavour) will do with them!

So to sum up perhaps the newer "clearfix" (the all in one sheet method) might look something more like this:

.float {
width: 49%; 
float: left; 
background: #fff; 
border-left: 1px solid #f00; 
text-indent: 10px;
}
 
.floatcontain {
background: #dad; 
border: 3px solid #000;
 
/* new compliant float clearance, includes IE7 support because it also triggers hasLayout */
 overflow: hidden;
}
 
/** Ye Good Ol' hasLayout trigger for IE5.5 thru IE7 - separate rulesets please! **/
/** note:  NO browsers object to this next part because of the cascade **/
 
.floatcontain { display: inline-block; }
.floatcontain { display: block; }

and to see it for yourself try the above with this HTML:

<div class="floatcontain">
<div class="float">first floated div</div>
<div class="float">second floated div</div>
</div>

and if you want to relegate "clearfix" to your IE archives then drop the inline-block and block rules and put them in a conditional sheet for [IE lte 6] or simply put in

.floatcontain {zoom: 1;}

Anyway hope that's not too much information and that it helps those who may come later or may have read misinformation in Books and certain websites. Only, in my experience it's only when you truly understand a hack does it help understand what the correct CSS should be

regards

[rochow]

Is there something I have overlooked? Why would anybody use a hacky, bloated, unsemantic thing to do something that can be done oh-so-much simpler?

Here's something I wrote a while back:

A common practice nowadays is to clear using a div, br or hr. I am going to Jackie Chan the next person who uses one, serious. Not only does it violate the fundamental rule (HTML is for content, CSS is for presentation) but it is both ugly and unnecessary. I am going to show you how using just CSS, you can produce the same effect, without all the mess!

The Theory
Let’s say you have a logo and a menu contained in a div named header. The logo is floated left, and the menu is floated right, and the div has a background image. Due to the way browsers deal with floated objects (great explanation, however poor solution) containers don’t “wrap” the floated elements inside it by default. So what you’ll notice is that in this example, the background image on the header will disappear!

The Bad Solutions
Add a <div style=”clear:both”>, <br clear”all” /> or <hr />

A common solution to this has been to add a “clear:both” whether on a div, br, hr or some other wacky tag which is inserted at the bottom of the header div after all the content. This makes the container wrap it’s floated elements. The problem is an emtpy tag has to be brought into the HTML to deal with a styling issue, which is meant to be taken care of in the CSS.

Add a clearfix class
Let’s avoid adding a non-semantic empty tag by adding a non-semantic class, yay! I’d rate this the worst of the lot as it’s trying to be clever by avoiding non-semantic markup yet it adds non-semantic classes (which is just as bad).

.clearfix:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}

Not only that, it doesn’t work in IE6 as it doesn’t support :after, so you have to use a * html hack or a conditional comment to feed it additional rubbish.

The Good Solution
You have an element you want to clear. Firstly, add “overflow:hidden” to the container in the CSS. This generally makes Firefox, Opera and Safari perfect. For IE 6, add a width:100&#37; (or px width if you don’t want 100%) which trips hasLayout, and that does the trick in most cases. If it wants to be a pain, float it. I do it in that order because there is no point floating the container if its not required.

#container {float:left;overflow:hidden;width:100%}

I'm not the best at turning what I do by habit into steps clearly, but what I do works fine, I can't see any reason to do it any other way.

[Skorzeny]

Float left + 100&#37; width are unnecessary (as you partly mention) and that container can’t take padding’s, margins nor borders , a nice property specially for div’s

Overflow hidden can't be used if you drag containers out of wrappers with negative margins

[Suzy]

Why would anybody use a hacky, bloated, unsemantic thing to do something that can be done oh-so-much simpler?

because it hasn't always been that way until very recently especially if your employer needed you to support those V6/7 browsers, FF2, Safari - hence the confusion with the older information I suppose?

That's what I mean when I say that I'm disappointed that the old info is being allowed to perpetuate, although I'm happy PIE updates the easyclearing page I wish they would update rather than change the information on their pages - it kind of makes those of us who do know look a little silly when we try to help newcomers cut through the other 6000+ pages out there to get to the truth

In all the overflow method is the right one, but even it has not been stable until very recently (wasn't it FF2/IE7 Paul?)

btw if you do use the well supported float method to contain floats you don't need overflow as well, and "float" also triggers hasLayout so technically you shouldn't need the width either but I realise that usually if you are using a float to contain child floats the outer one needs a width so the other floats inside it know how much room they've got.. (or else it would shrinkwrap)..

which brings with it the main reason why floats to contain other floats can't always be used, it is not that simple when you are trying to incorporate floated content elements into a variable width "main content" area which is already sitting beside a floated sidebar. The width your containing float might need to be would be 100&#37; of the window/layout less the width of the sidebar.. which cannot yet be determined without a script, which brings the circle back to overflow and hasLayout - overflow:hidden on the maincontent div (if you've got one available) would make it contain the child floats horizontally as well as vertically but you would still then need hasLayout also set on it for IE6 and below - so you can then safely use the floats in a float method @ width 100% inside the main content area.. but again that has only been possible very recently ..horses for courses we are slap bang in the middle of what should be versus what we still have to support


PS: ewwatson, if you're still reading.. using a space rather than a dot should be fine, when the technique originally surfaced circa 2003, Moz 1.4 and I don't know how many later versions actually needed something inside the quotes in order for it to work (I too have no knowledge of it breaking with the dot.. more likely it is breaking because it is conflicting with a previous float, or possibly because the hack is not properly implemented due to the misinformation about it?.. anyway without a test case it's impossible to say).. as for the space then not needing the height/font-size bits, that is probably true.. it was IE who used to still give height to empty elements and as this is not for IE it should be good to go without them, but do your own research - anyway I hope you see that this whole thing has always ever been a moving target and perhaps just a note of that on your site would help clarify that for others? my advice is choose what you understand, and PPS: that Perishable Press article was updated on July 9th because of something Jeff Starr picked up from me via another article

[Paul O'B]

Is there something I have overlooked? Why would anybody use a hacky, bloated, unsemantic thing to do something that can be done oh-so-much simpler?

Here's something I wrote a while back:

The overflow method has already been mentioned a few times in this thread

Anyway hope that's not too much information and that it helps those who may come later or may have read misinformation in Books and certain websites. Only, in my experience it's only when you truly understand a hack does it help understand what the correct CSS should be

Thanks Suzy for taking the time to make a wonderful, insightful and thoughtful post. I think you addressed all the issues nicely.

Overflow hidden can't be used if you drag containers out of wrappers with negative margins

Yes that is a downside with the overflow method and in those cases one of the other clearing techniques should be used.

[rochow]

Float left + 100&#37; width are unnecessary (as you partly mention) and that container can’t take padding’s, margins nor borders , a nice property specially for div’s

Add overflow:hidden in IE6 and see how it goes.

The overflow method has already been mentioned a few times in this thread

Mustn't have seen those, in all the posts I read everyone was talking about how great the clearfix method is.

btw if you do use the well supported float method to contain floats you don't need overflow as well, and "float" also triggers hasLayout so technically you shouldn't need the width either but I realise that usually if you are using a float to contain child floats the outer one needs a width so the other floats inside it know how much room they've got.. (or else it would shrinkwrap)..

I probably didn't word it right. Basically:
- overflow:hidden for every browser except IE6
- width:100% -or- float:left for IE6 (or height:1% or zoom:1, but that's getting hacky)

You wouldn't use both unless it was float:left;width:525px; or something

Like anything, the situations in which you use it determine the solution. If you have things that are positioned outside of the div, overflow:hidden won't work, so floating could be the better way of doing things (again, depending on the situation)

Either way, never have to use the .clearfix method!

[PicnicTutorials]

PS: ewwatson, if you're still reading.. using a space rather than a dot should be fine, when the technique originally surfaced circa 2003, Moz 1.4 and I don't know how many later versions actually needed something inside the quotes in order for it to work (I too have no knowledge of it breaking with the dot.. more likely it is breaking because it is conflicting with a previous float, or possibly because the hack is not properly implemented due to the misinformation about it?.. anyway without a test case it's impossible to say).. as for the space then not needing the height/font-size bits, that is probably true.. it was IE who used to still give height to empty elements and as this is not for IE it should be good to go without them, but do your own research - anyway I hope you see that this whole thing has always ever been a moving target and perhaps just a note of that on your site would help clarify that for others? my advice is choose what you understand, and PPS: that Perishable Press article was updated on July 9th because of something Jeff Starr picked up from me via another article

I'm always reading along - like a sponge! Hi Suzy, how are you? I still remember when you stuck in there with me and helped me solve the firefox rounding error bug - remember? Thanks again for that! Yes this is a good ending to this thread. Thank you for all invaluable information! Yes, I linked to this thread when I created my tut (method #2) on this subject two months ago or so. So thank to you, now it's even more pertinent! Also, thank you again to Paul O'B for helping me with the display:table; one (method #5). Also, two months ago or so when I was testing all this, the clearfix with a "space" instead of a "dot" performed exactly the same on 70 plus browsers tested (via browser shots). That's all - have a good one!

[D9r]

Dan Cederholm suggested at An Event Apart SF to use the class name ".group" rather than ".clearfix" as it actually has some semblance of semantic meaning.

I'm all for it!

I think encapsulate is good name because it describes exactly what the class does. The element that has this class encapsulates what is inside it. Better than clear or group I think. The element with this class or style isn't clearing anything really so I think that clearfix,cleat,ect is inappropriate and doesn't fully describe the purpose.

Agreed. "group" is a tad generic. I guess for me "group" is memorable because I'm a big fan of Dan and I finally got to see him speak in person and this was one of his ideas he threw out.

"encapsulate" is an excellent idea. However, personally I think I'd be prone to mistyping it!

Liking the idea of "encapsulate", but fearing I'd habitually mistype it, I went searching for alternatives.

Anyhow, after a little digging I came to like "bound" for its implied semantics and for its ease of typing and brevity.

However, if any of these class names take off, I'd think it would be "group" simply because it's endorsed by Mr. Cederholm.

How about binder? It's semantic, short and easy to type, and difficult to misspell.

Here's the definition:

binder:
1. a person or thing that binds.
2. a detachable cover, resembling the cover of a notebook or book, with clasps or rings for holding loose papers together: a three-ring binder.
3. a person who binds books; a bookbinder.
6. Chemistry. any substance that causes the components of a mixture to cohere.
7. Painting. a vehicle in which pigment is suspended.
8. (in powder metallurgy) a substance for holding compacted metal powder together while it is being sintered.
9. Building Trades.
a. a stone, as a perpend, for bonding masonry.
b. a girder supporting the ends of two sets of floor joists.
c. a material for holding loose material together, as in a macadamized road.

http://dictionary.reference.com/browse/binder

[Stomme poes]

Why use those names, when the technique itself is called "enclosing floats"??

I understand the spirit of what you're saying, but I'm pretty sure the originator of the "clearfix" class was not named Mr. Clearfix...

Lawlz. It was a fix for the clearing problem. I dunno if Tony even started with that name though.

There is one place to use this nasty clearfix. I have managed to avoid it everywhere but yeah, IF you cannot screw with overflow because of (in my case) CSS tooltips, and if you cannot use another element inside the container to clear, and if display: table screws your container too much (I've just seen this in Opera though it really takes a lot of code to get it to die), then you'll need the nasty clearfix. It works, it's a final-solution-after-everything-else dies, and often can be shorted since a lot of that font-size and junk was for Mozilla 2 and old FF which, depending on your audience, could be ignored, along with IE/Mac, and the Haslayout can often also be normally incorporated into the regular code (as Rochow did). I'll add a 100% width to things which are already 100% wide just for Haslayout, sure.

[ssauble]

inline-block gives extra spacing because of the spacing in mark-up. It creates an extra 4px. One way you can get around it is by utilizing letter-spacing. I'm creating a new clearfix and will post after I'm done with the project I'm on.

[Paul O'B]

inline-block gives extra spacing because of the spacing in mark-up. It creates an extra 4px. One way you can get around it is by utilizing letter-spacing. I'm creating a new clearfix and will post after I'm done with the project I'm on.

I'm not sure why you didn't post your full solution as it wouldn't have taken you much longer to type lol ?

Now I'm going to have to guess

I think you may be confusing your bugs and inline-block is nothing but a haslayout trigger which is then reset to display:block so the element doesn't behave as an inline-block anyway.

Read suzy's earlier thorough post on the subject as you won't find a better explanation around.

I'm guessing that you have a floated element that has a height less than the current font-size and therefore IE will expand the parent because it is in haslayout mode and will at least accommodate the full line-height /font-size of the element. This is an old bug and nothing to do with clearfix and you simply need to reduce the font-size of the small height element to zero or set overflow:hidden to hide the excess.

If you are talking about the behaviour of inline block elements then taht's a separate question and yes they are subject to whitespace nodes between blocks and their vertical alignment will be baseline by default leaving a gap below for descenders.

[ssauble]

Some of us are busy. Hats off to Suzy for her contribution but it is not all-encompassing.

Paul, I apologize for my unnecessary post as it was not at all informative but if your Staff Membership allows you the ability to ban me from SitePoint, please do before I say something condescending.

[Paul O'B]

Paul, I apologize for my unnecessary post as it was not at all informative but if your Staff Membership allows you the ability to ban me from SitePoint, please do before I say something condescending.

Apology accepted and I look forward to your solution