But the browsers they are changing, and we have to face the problem that depending on the bugs that are fixed in IE7 and up, inevitably hacks for IE6 might break in (or be detrimental to) new versions of the browser, or new browser versions with similar layout bugs might not deliver filters like * html anymore. In this light, the use of the MS proprietary zoom, can be advised.

1. <!--[if lt IE 7]><style>
2. /* style for IE 6 + IE5.5 + IE5.0 */
3. .gainlayout { height: 0; }
4. </style><![endif]-->
5.  
6. <!--[if IE 7]><style>
7. .gainlayout { zoom: 1;}
8. /* or whatever we might need tomorrow */
9. </style><![endif]-->

• zoom: 1; gives layout in IE5.5+ to any element (including inline elements), but it has no effect in IE5.0
• No known side effects (inline elements behave like inline-block, though).
• If validation is required, zoom must be hidden via conditional comments.

While we think “future proof” is a contradiction in terms, we strongly suggest the web designer “plays for sure” and review her pages for explicit and implicit “hacks” and use conditional comments to serve those hacks to the appropriate browser version.

A workaround?

We could trigger “hasLayout” by adding, for example, a dimension or zoom: 1 to the parent. But this urges the parent to enclose the float automatically, even if there is no clearing element. This is the auto-containing bug in IE/Win: By design, “layout” establishes a new block formatting context.

If applying hasLayout is not an option in certain design situations, IE6 and IE7 may render more stable if the float does not join the clearer in the source code, i.e. by separating them with an additional element.

Conclusions: An AP box sometimes disappears when in the source code it is the preceding or the following sibling of a float. This condition doesn't always trigger the problem, but seems necessary for the problem to happen. So any box (even an extra dummy div) "separating" the AP box from the float in the source code (either being between them, or wrapping one of them) fixes the problem. If anyone knows a better explanation or a better fix for this problem please let me know.

The solution for the duplicate characters and doubled margin problems is, as stated above, to simply specify display:inline for the floated element. The fact that the display property clears the bug is really interesting seeing how it is really supposed to do, well, nothing! (For more information on float in combination with display, please consult W3C)

What about the other bugs? Does display:inline work on them as well? Well, not quite... But, a non-existing value for the display property does -- inline-block! For the 3px jog and creeping text problems, simply apply display:inline-block to the element itself. For the peek-a-boo and unscrollable content problems, apply display:inline-block to the containing element (=parent/wrapper).

 this really blows my mind

It's an unfortunate fact that Internet Explorer will always incorrectly expand any dimensionally restricted block element so that oversize content is unable to overflow, as the specs require that content to do. I will be comparing IE/win's way with the correct behavior as seen in Firefox. The W3C says a rigidly sized block box should allow oversize content to protrude or overflow beyond the edges of the sized box.

How Do You Fix It?

The work around for this bug is preposterously simple, counter-intuitive and utterly in violation of the W3C recommendations—simply change the style of the floated element to "display: inline" and the problem disappears.

The Microsoft Internet Explorer Developer Toolbar provides a variety of tools for quickly creating, understanding, and troubleshooting Web pages.