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

[PicnicTutorials]

So I'm working on my demo here and now I move onto the clearfix method. While doing some reading I came across this article by Perishable Press. As Paul would put it, he amalgamated the clearfix method a little. Makes sense to me - what do you think? Heard anything about his changes? I understand the reasoning behind the font-size: 0; but what about the space void of the "dot". Thoughts???

Also, if I wanted to remove IE5 from it would it look like this? That's who the hacky stuff is for right?

.clearfix:after {
content:".";
display:block;
height:0;
clear:both;
visibility:hidden;
}
.clearfix {display:inline-block;}
* html .clearfix {height: 1%;}

[PicnicTutorials]

Bump! And here is the amalgamated version.

/* slightly enhanced, universal clearfix hack */
.clearfix:after {
visibility: hidden;
display: block;
font-size: 0;
content: " ";
clear: both;
height: 0;
}
.clearfix { display: inline-block; }
/* start commented backslash hack \*/
* html .clearfix { height: 1%; }
.clearfix { display: block; }
/* close commented backslash hack */

[PicnicTutorials]

I'm surprised nobody has a comment for this. No one knows the answer, or know one cares? I did a lot of testing with it all and I came to two conclusions. One: I'm not even going to attempt to mess with the hacky stuff at the bottom of the .clearfix for IE5 (or whom ever it's for) - because apparently, IE7, and 6 need those rules at the bottom of the clearfix to work (to provide "haslayout" or something). And Two: the clearfix DOES work perfectly with the "space" instead of the "dot". Because I don't really even understand exactly how it's doing it (I understand enough to know that I don't understand it fully) - which is better - the "dot" or the "space"? The font-size:0; is harmless so I'll probably just include it anyways. Thanks for indulging my tendency for perfectionism!

[Paul O'B]

but what about the space void of the "dot". Thoughts???

I would like to have seen examples of when the dot was breaking layouts although the font-size:0 is probably worthwhile to avoid any extra space. I have never come across an issue of when the dot has broken any layout but I just might be lucky

Also, if I wanted to remove IE5 from it would it look like this? That's who the hacky stuff is for right?

Some of the hack is for ie5 mac but now you've reduced it its wrong

This is for ie5 mac and also to give ie7 haslayout so that it will clear.

.clearfix { display: inline-block; }

The commented backslash hides the following styles from ie5 mac.

/* start commented backslash hack \*/
* html .clearfix { height: 1%; }
.clearfix { display: block; }
/* close commented backslash hack */

The height:1% is for IE less than version 6 (not iemac) and gives the element "haslayout" so that it auto clears.

The display:block is for IE7 to over-rule the previous display:inline-block rule. Even though it over-rules the previous rule the element still maintains "haslayout" from the previous display:inline-block setting. That's why the order of the code should not be changed or amalgamated.

What else did you want to know

[PicnicTutorials]

I would like to have seen examples of when the dot was breaking layouts although the font-size:0 is probably worthwhile to avoid any extra space. I have never come across an issue of when the dot has broken any layout but I just might be lucky

Yes me too! In fact, I just combed that page again this morning looking for that.

The display:block is for IE7 to over-rule the previous display:inline-block rule. Even though it over-rules the previous rule the element still maintains "haslayout" from the previous display:inline-block setting. That's why the order of the code should not be changed or amalgamated.

Thats what I didn't fully understand (although that's what I "thought" must have been going on I just couldn't prove it). That you could override it yet IE7 still maintains "haslayout" even once it was overridden. Strange, I removed inline-block earlier while testing and replaced it with min-height: 0; - that did not work. Thats probably was what was adding to my confusion.

What else did you want to know

I guess the only thing else I wanted to know was "if" I wanted to remove IE5 mac from it would I then just remove the /*mac hide \*/ comments? Because, like you said - display inline-block is for IE7 also. From what I've been told, IE5 is at less than 1%. Thanks a lot for information Paul!

[Paul O'B]

Thats what I didn't fully understand

Claire (Suzy) Campbell explains that here.

[PicnicTutorials]

Alright, thanks a lot Paul, Suzy's article helped make it all clear! I went with the "space" and font-size: 0; method. It works perfectly! I figure if it works without the "dot", then why add it ya-know.

This quote from his website helped win me over - I like his attitude!

Another bizarre inconsistency involved with clearfixed (probably not a real verb) layouts seems to disappear when the font-size property is included in the hack and subsequently set to zero. This may be overkill when using a blank space instead of an actual dot (as described above), but I honestly don’t care. I’m like some sort of CSS animal — using every available weapon to fight hellish layout battles.

[cooper.semantics]

So I'm working on my demo here and now I move onto the clearfix method. While doing some reading I came across this article by Perishable Press. As Paul would put it, he amalgamated the clearfix method a little. Makes sense to me - what do you think? Heard anything about his changes? I understand the reasoning behind the font-size: 0; but what about the space void of the "dot". Thoughts???

Also, if I wanted to remove IE5 from it would it look like this? That's who the hacky stuff is for right?

.clearfix:after {
content:".";
display:block;
height:0;
clear:both;
visibility:hidden;
}
.clearfix {display:inline-block;}
* html .clearfix {height: 1%;}

I found that the display: inline-block; needs to be only read by ie7. Is quirky in safari.

Apply this: *:first-child + html .clear {
display : inline-block;
}

[PicnicTutorials]

I found that the display: inline-block; needs to be only read by ie7. Is quirky in safari.

Apply this: *:first-child + html .clear {
display : inline-block;
}

Hi,

IE7 needs display block as well. Normally they would just over right each other. But not when it comes to "haslayout". IE gets layout from display inline-block and then that gets overridden by display block but IE keeps "haslyout". It's called the trip switch. But the two rules also have to be separated by another in order to work. So basically, the only things you can safely eliminate are the mac hack comments if you don't care about IE5 Mac.

So this is how it should and needs to look.

.clearfix:after {
content:" ";
display:block;
height:0;
font-size:0;
clear:both;
visibility:hidden;
}
.clearfix {display:inline-block;}
/* mac hide \*/
* html .clearfix {height:1%;}
.clearfix {display:block;}
/* End hide */

Or if you don't care about IE5 Mac then it would look like this.

.clearfix:after {
content:" ";
display:block;
height:0;
font-size:0;
clear:both;
visibility:hidden;
}
.clearfix {display:inline-block;}
* html .clearfix {height:1%;}
.clearfix {display:block;}


Alternatively you can code it with CC's instead like this

.clearfix:after {
content:" ";
display:block;
height:0;
font-size:0;
clear:both;
visibility:hidden;
}
.clearfix {display: inline-block;} /* for IE5/Mac and IE7 */

<!--[if IE]>
<style type="text/css">
.clearfix {
zoom: 1; /* triggers hasLayout */
display: block; /* resets display for IE/Win */
}
</style>
<![endif]-->

Or if you don't care about IE5 Mac then it would look like this.

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

<!--[if IE]>
<style type="text/css">
.clearfix {
zoom: 1; /* triggers hasLayout */
}
</style>
<![endif]-->

[rabbitsfeat]

What do you make of this method? Seems a lot simpler.

[PicnicTutorials]

Hi, my vote?

From preferred to least preferred

1) overflow: hidden;
2) .clearfix
3) clearing div
4) floated parent
5) display: table;

[rabbitsfeat]

That's interesting where you put display: table—I didn't actually know that could be used to clear. I've just gotten rid of it on a site I'm building because it was causing strange layout behaviour. I had some much grateful help from Sitepoint members with this.

Reading one of the articles you refer to above I noticed this:

the deprecated use of the inline value for the display property

Is this true? Could you confirm that using inline as a value for the display property is deprecated?

Is there any documentation detailing this on the web somewhere?

Back to more reading—this is a very interesting post. Thank you.

[PicnicTutorials]

Your welcome! If you read the comments at the bottom of the article he tries to explain why he said that. No, display inline is not deprecated, and to my knowledge, nor will it ever be!

[rabbitsfeat]

Yeah thanks I just read on a bit. Thanks anyway, I was a bit worried there.

[cooper.semantics]

Hi,

IE7 needs display block as well. Normally they would just over right each other. But not when it comes to "haslayout". IE gets layout from display inline-block and then that gets overridden by display block but IE keeps "haslyout". It's called the trip switch. But the two rules also have to be separated by another in order to work. So basically, the only things you can safely eliminate are the mac hack comments if you don't care about IE5 Mac.

So this is how it should and needs to look.

.clearfix:after {
content:" ";
display:block;
height:0;
font-size:0;
clear:both;
visibility:hidden;
}
.clearfix {display:inline-block;}
/* mac hide \*/
* html .clearfix {height:1&#37;;}
.clearfix {display:block;}
/* End hide */

Or if you don't care about IE5 Mac then it would look like this.

.clearfix:after {
content:" ";
display:block;
height:0;
font-size:0;
clear:both;
visibility:hidden;
}
.clearfix {display:inline-block;}
* html .clearfix {height:1%;}
.clearfix {display:block;}


Alternatively you can code it with CC's instead like this

.clearfix:after {
content:" ";
display:block;
height:0;
font-size:0;
clear:both;
visibility:hidden;
}
.clearfix {display: inline-block;} /* for IE5/Mac and IE7 */

<!--[if IE]>
<style type="text/css">
.clearfix {
zoom: 1; /* triggers hasLayout */
display: block; /* resets display for IE/Win */
}
</style>
<![endif]-->

Or if you don't care about IE5 Mac then it would look like this.

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

<!--[if IE]>
<style type="text/css">
.clearfix {
zoom: 1; /* triggers hasLayout */
}
</style>
<![endif]-->

Looks good, display: inline-block renders strangely in safari but since you have the display: block below display: inline-block it fixes the issue.

[AnalogPanda]

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!

[oddz]

.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 */

Straight from Web Standards Creativity with some class name changes. Its the one I prefer. 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.

[cooper.semantics]

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!

One thing that caught my mind is that he has a class named hide.

hide, clear Same difference.

You should remember that classes such as these need to be easiest for you the developer to remember.

[AnalogPanda]

You should remember that classes such as these need to be easiest for you the developer to remember.

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.

But I've been trying to forget "clearfix" for so long now (I cringe when I see it in my markup) that I'm happy to have a name that feels much less hacky.

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

[PicnicTutorials]

I try and keep my names short and memorable. I and most others that use the .clearfix name in their demos and such, probably do so out of respect for the original creator of the technique. Sort of like if I wrote an article about Hopkins Disease. Sure I could probably think of a much better name for it. But it's named after the man that first discovered it. So that's the name people use when they refer to it. Listen to me... I sound old and mature. Oh no!

[AnalogPanda]

Liking the idea of "encapsulate", but fearing I'd habitually mistype it, I went searching for alternatives. Would you believe that thesaurus.com doesn't have an entry for "encapsulate"? How lame is that?

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.

[AnalogPanda]

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

There's a story I heard a bout a lady who would cut off the ends of a ham before cooking it. When asked why she cut the ends of the ham before cooking it, she replied "because that's how my Mom did it"

The woman never really questioned the technique of cutting off the ends of the ham and became quite curious. So she asked her mother why she cut the ends of the ham before cooking it. Her mother replied "because that's how your grandmother did it"

Curious still, the woman asked her grandmother why she cut the ends of the ham before cooking it and she replied "that's how your great grandmother did it"

So the woman paid a visit to her great grandmother who was very old but was still very sharp. She asked her great grandmother why she would cut the ends of the ham before cooking it, to which her great grandmother replied "because I had a very small pan"

The point is, some things don't necessarily need to stay the same. And I think it's quite good that we reexamine tried and true practices from time to time.

[oddz]

Yeah, encapsulate was something I stirred up because it has always annoyed me to call it clear anything because it doesn't actually clear anything unless your using clearing divs instead. Group doesn't seem appropriate because its really not a group either. A group could be anything. A group doesn't necessarily need to encapsulate its children. Thats not really what defines a group. A group is series of related items. The items being encapsulated may not even be related only be within proximity to one another.

[AnalogPanda]

@oddz - Well put. "group" does imply that the members of the group have some sort of relationship. And quite often, the floated items within a containing element don't really have a relationship. Thus, "encapsulate" and "bound" both seem to make sense.

[rabbitsfeat]

This is an interesting discussion.

The name clearfix has always confused me because as you've said already, it doesn't really clear anything. It groups or encapsulates (probably would make typos with that) what's within the element it's being applied to—hope I got that right?

It's the :after bit of this name that confuses me the most. It groups or encapsulates what's within the element it's being applied to, which results in anything coming after this element being cleared. I've always read the name in its entirety (clearfix after), so group or encapsulate after would read to me: group or encapsulate what comes after, yet it's not really applied to anything that comes after—it just influences it. I guess it depends on how you read or understand the rule.

It's a tricky one this. I agree that clearfix is confusing, but I'm not sure if group or encapsulate or similar words make it any less confusing, or really explain what is happening.

If I were to come up with a name that explained exactly what is going on (semantic meaning) I'd probably use something like: wrapClear:after

Because it wraps up what's within the div it's being applied to and then clears after.

This is how I understand it.