QFT

sadly i still use the old br class=”clear” routine it’s the easiest to remember and works for all browsers

Something like
clear-children: clear/none;

In all honesty should be set to clear by default. There have been times when I didn’t want to clearfix, but they’re rare enough that it shouldn’t be the norm. Although, float wasn’t designed for what we’re using it for. There really needs to be an alternative to float. I’m not terribly excited about the CSS3 Layout but it may be the way to go.

My problem with a lot of CSS how-tos is they assume a small pool of developers, a tightly controlled codebase, and a relatively static site. In the real world, many of us work on huge sites maintained by global development teams, which requires defensive coding techniques. These apps must be skinnable – the same markup powering multiple white-labelled instances, sometimes on a variety of platforms (mobile/browser/etc.). They also rely on templating systems that may compose any arbitrary set of modules into pages; the CSS mustn’t break as a result of any specific configuration.

The techniques that work for a mostly static, content-based site must be adapted for a complex webapp with multiple white-labelled instances. Thanks again to Gena for helping me illuminate why this particular solution worked well for one particular such app.

We were building a site that needed to be as fully skinnable/customizable as possible without needing changes to markup (but was allowed unlimited CSS differences via independent stylesheets). Needing to enclose floated elements vs. not wanting to do so was not a good enough reason for changing the markup. And in the interest of code transparency it was important to not have something like “clearfix” ever overwritten to not enclose floats. It would be like having a class of “pinkBorder” that’s set to be green in some implementations — uncool, especially in a multiple developer environment.

We also knew that designers sometimes like to employ the technique where graphics or text extend out of their parent container (but semantically, still belong inside it). (Like a “New/Improved” graphic overlapping the corner of an element.) For those cases, we needed overflow: hidden not to cut off that escaping content, and overflow: auto not to force scrollbars on it (even though in many other circumstances either would be more elegant). And don’t even get me started on overflow: auto + a floated parent + Safari 2.

Lastly, we wanted our CSS to validate, which prevented the use of proprietary IE properties like “zoom” or things like the underscore hack.

We went with the above technique for those reasons; it’s most flexible for what we needed.

Finally, while this problem is often discussed in terms of float clearing, it may be useful to clarify that the code above causes parent elements to *enclose* their floated children. If browsers and designs supported it, it could be just as effective, and probably more transparent, to select the first subsequent sibling of div.containerWithFloats and add the appropriate clear (left/both/right) rule. (Because this technique describes how to make div.containerWithFloats, due to its float enclosing, have subsequent elements no longer need to clear it.)

If your text content is dynamic and/or the width of the text column is dynamic, you cannot be sure the text will extend the height of the image without clearing the image float.
If you want more than one image in the text paragraph, the same applies.

So in my opinion you need to clear an image float in text paragraphs more often than not

If you’ve ever floated an image next to a block of text, then you’ve witnessed an instance where you did not have to clear your floats.

Remember, that’s what the originally conceived context of floated elements was intended to address.

see this article by eric meyer from 2003
http://www.complexspiral.com/publications/containing-floats

#container {overflow:hidden;}

that for ‘real’ browsers.

Add zoom:1, _height:1%, width:(something) to trigger haslayout and you have it for ie6 and up (I usually have a separate stylesheet and conditional comments for that, so _height can be just height)

Needless to say that if #container already has a width value due to it’s own nature all the ie stuff is not needed.

Cheers from Spain