Peek-a-boo IE6 Bug

The setup:

A liquid box has a float inside, and following content that appears alongside the float. All is well until it's viewed in IE6. "Wah? Where's my content?!" You reload the page, and still nothing. Then when you scroll down or perhaps switch to another window, upon returning to the "scene of the crime" there it all is, fat 'n sassy! Sometimes it waits until you reload before the theft occurs. Very odd.

To reset bug, reload page. Screenshot

The demo:

div.floatholder (dotted border) is dimensioned horizontally by margins, and vertically by content. div.float (thick brown border) is floated left, and contains a test link. Following that are several lines of bare text, alternating with divs containing more text, plus test links. Next is a cleared div (purple border), then another div for good measure.

The bugs:

This effect may turn up in a number of different contexts. We would try to list them here, but the page would become very long and generate waves of brain pain.

Fun with links:

First reload to make sure the bug is in effect. Then try clicking the links. This will reveal the missing content, same as scrolling. If the float is a linked image, same deal. But only links within div.floatholder, and before the clearing div will expose the missing content.
But check out the last link in the content area. Weird! If you approach the links from below all sorts of hides and reveals are possible.

Special notes:

The bug appears to be primarily triggered by the clearing div. When it is forced to clear a float, the content following after the float gets covered somehow, perhaps by the background on div.floatholder (dotted border). Also, a page with multiple repetitions of the floatholder div with its triggers can behave very strangely.

The demo does not suffer from the missing content bug if any of the element types that precede it are duplicated, meaning a second h1, h2, or p before the demo. However the link funkyness remains. Also, even a single character before the demo but not within one of those semantic elements (h1, h2, p etc.) will prevent the hiding.

Font-size and padding sometimes has an effect on this bug, even when applied outside the demo itself, but the details have not been worked out due to the aforementioned brain pain, and because fixing the bug makes understanding it unnecessary. Not that we are claiming we could actually figure out what is going on inside IE. That would require very potent drugs indeed...

Finally, this bug will be triggered even if div.float preceeds div.floatholder rather than being nested in it, provided that this external float actually touches the clearing div within div.floatholder!
(IE float bugs are so cool)

The fixes:

There are several known ways to prevent this bug.

Keep the clearing div from touching the float, or avoid using a background on div#floatholder. Not exactly ideal, we know.
Give div.floatholder an explicit 'width' or 'height'. Also quite restrictive.
Assign 'position: relative' to both div.floatholder and div.float. Be sure to fully test this method.
Matthew Somerville found that any 'line-height' assigned to div#floatholder quashes the bug. Be aware that you might have individually set line-height for child elements having different font-sizes or risk text bugs in IE.
Flash! The newly discovered Holly hack (Dec 3, 2003) can also fix this bug, by assigning a "false height" that only IE/win can see. This height gives IE the dimension it needs without disturbing the width or affecting other browsers, and without the potiential bugginess associated with the use of 'relative'. Because the Holly hack is so trouble free it is now the preferred fix for the Peekaboo bug.

The Holly Hack

It may seem strange, but a height can be given to IE/win and not affect the displayed height of the container. This is possible because IE has a non-standard behavior concerning boxes and dimensions. When IE/win sees that a box has a stated dimension that is not large enough to enclose the content of the box, IE/win goes ahead and wrongly enlarges the dimension so that the content does not overflow the box borders. Tsk.

You might think this is a good idea, but if the box is a float and it gets enlarged beyond its stated size it may be forced to drop down the page to where it has more room, wrecking the layout.

Anyway, Since IE/win will behave this way, a very small height can be applied to the container and IE/win will just make the box taller anyway. Thus a small height does not change the appearance of the box, but the Peekaboo bug is fixed!

All that remains to complete the fix is to hide the height from all browsers except IE/win. So here is the Holly hack proper:

/* Hides from IE-mac \*/

* html .floatholder {height: 1%;}
/* End hide from IE-mac */

The first line is a CSS comment with an "escape" (colored red) just before the comment closing tag. because of that escape, IE/mac ignores the closing tag and thinks the comment is still active. Thus it ignores everything until it sees a CSS comment closing tag. The last line is a normal comment, and its closing tag is what lets IE/mac begin parsing code again.

The second line has a "universal" selector followed by "html" (also red), followed by the targeted element. This selects .floatholder when it is nested within html (true), and also when 'html' is nested within any element. It so happens that IE browsers have an invisible and mysterious wrapper element around 'html', so this selector works in IE and nowhere else. IE/mac must be prevented from seeing this height because it does not have the Peekaboo bug, and also does not enlarge the box like IE/win.

Seen below is the exact same demo as above, with the single addition being the Holly hack 'height' applied to div.floatholder. Only IE6 really needs it, but it does not harm previous IE/win versions so there is no need to hide it from them.