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?
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.
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.
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 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!
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.
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.
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!
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.
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.
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.
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!
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.
