In IE, floats are auto-contained by elements that have “layout.” Sometimes, this auto-containing might be not desired. The following tests show a floating logo that should stick out of its parent header, a DIV. Subsequent boxes should respect this float.
Important: This preliminary information on the IE7 beta 2 preview is subject to change!
A specified height for a container will be respected since IE7b2, meaning that this layout trigger stops the extend-to-fit, or auto-containing behavior of previous IE versions. Because of layout, the float still “belongs” to that container, and shares the layout bugs that may be related to the container; the float just sticks out of it (see test B).
| Test | Fx1.5 | IE6 | IE7b2 |
|---|---|---|---|
A[ test A ] |
 |
The navy #header element expands to fit the yellow float (and the margin-bottom of the |
Identical to IE6 (although the wrapper is dotted, not dashed). |
B[ test B ]
|
 |
The extend-to-fit ignores the given height, and the header already has layout due to the width applied. |
A specified height for the header stops the extend-to-fit behavior in IE7. Subsequent elements do not respect the float, however. The float gets the “layout stacking order” from its parent, meaning that subsequent layout elements like the |
C[ test C ]
|
Overflow set to something other than auto establishes a new block formatting context, therefore, the float is contained. |
Layout has already established something similar to a new block formatting context. |
Identical to IE6. |
D[ test D ]
|
 |
The explicit height is respected with |
Identical to IE6. |
E[ test E ]
|
|
|
Identical to IE6. Compared to test B, the |
In standards mode IE6, we can force the #header to respect a given height with overflow: hidden, and we can prevent the logo from being cut off with position: relative (using another bug in IE, as hidden should mean hidden).
The painful reality is that this logo is not only taken out of the flow as floats are, but it is also not respected by subsequent elements, be they floats, or clearing elements, or whatever (see test E).
And that's basically what happens in IE7b2 with a float that hangs out of its height-specified container (see test B and IE7b2: Floats in specified height containers are ignored by following boxes).
As a side note, these tests show not only the erroneously implemented CSS stacking context, but also the proprietary “layout stacking order” (see On having layout: The stack, the layering, and layout).
Even worse: An element with the clear property can't affect a float outside of the clearer's layout container, nor does it clear a float that “belongs” to another layout container (see test B + E).
Another approach to solving the problem: Don't let the containing header gain “layout.” However, it is not realistic to abstain from the use of implicit haslayout-triggers like height or width in more complex designs. And this dilemma is aggravated by the need for bug fixes that apply haslayout.
Other options: use position: absolute for the logo, or make a change in the markup and take the float out of the #header. Perhaps these are appropriate solutions in certain instances.
Float layouts relying on these bugs cannot be transferred to work in a compliant browser without a general re-do, and layouts designed according to the specification may be not transferable into IE. All these bugs occur because of the same problem, that is; a container that has “layout” forms a sort of a block formatting context. This is explained in On having layout: Similarities with the CSS specs.
The bottom line: While the absence of “layout” can be the cause of bugs that are comparatively easy to fix with haslayout hacks, it is the inevitable presence of “layout” that causes more worries.
