acidic float tests

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).

The float test results are shown in screen shots.
The following elements have “layout”: The blue header (width), the semi-transparent yellow logo (float), the subhead (width), and the white dotted wrapper (width).
Test Fx1.5 IE6 IE7b2

A[ test A ]

Fx1.5 screenshot a IE6 screenshot a

The navy #header element expands to fit the yellow float (and the margin-bottom of the h1 headline, but that's another bug).

IE7b2 screenshot a

Identical to IE6 (although the wrapper is dotted, not dashed).

B[ test B ]

#header { height: 7em; }

Fx1.5 screenshot b IE6 screenshot b

The extend-to-fit ignores the given height, and the header already has layout due to the width applied.

IE7b2 screenshot b

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 h2 subhead are rendered above this float, and non-layout elements like the clearer are rendered under the protruding float. Note that even the white dotted wrapper, which itself has layout, does not expand to contain this float.

C[ test C ]

#header { overflow: hidden; }

Fx1.5 screenshot c

Overflow set to something other than auto establishes a new block formatting context, therefore, the float is contained.

IE6 screenshot c

Layout has already established something similar to a new block formatting context.

IE7b2 screenshot c

Identical to IE6.

D[ test D ]

#header { height: 7em; overflow: hidden; }

Fx1.5 screenshot d IE6 screenshot d

The explicit height is respected with overflow: hidden. The result is equal to the expected rendering.

IE7b2 screenshot d

Identical to IE6.

E[ test E ]

#header { height: 7em; overflow: hidden; }

#logo { position: relative; }

Fx1.5 screenshot e

overflow: hidden is respected, the float remains cut off.

IE6 screenshot e

position: relative, together with layout, incorrectly forms a stacking context in IE. overflow: hidden is not respected anymore. The float sticks out of its container. Subsequent elements do not respect this float.

IE7b2 screenshot e

Identical to IE6. Compared to test B, the h2 subhead does behave differently. The stacking order of position: relative is higher than the “layout stacking order.”

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.

Created, and last updated:
Feb. 13th, 2006
Feb. 28th, 2006
Holly Bergevin
Ingo Chao
Bruno Fassino
Georg Sørtun
Philippe Wittenbergh
Copyright notice:
This work is published under a Creative Commons license.