K-U-H-N.net

Introduction

Let's have a look at IE's Collapsing Block Box bug... yes, say that 3 times fast. This bug causes IE to collapse a block box containing an inline element to the inline element's height in disregard of the block boxes line-height. This behaviour is a violation of the CSS specs as

in a "block-level [...] element whose content is composed of inline-level elements, 'line-height' specifies the minimal height of line boxes within the element. The minimum height consists of a minimum height above the block's baseline and a minimum depth below it, exactly as if each line box starts with a zero-width inline box with the block's font and line height properties.

Affected Browsers

In IE 5.5 this bug affects all block elements, in IE6/7 all non-list block elements. The bug has been fixed in IE8. Note that standard browsers behave the same way with (x)html transitional doctypes, with the fix below havin no effect.

Conventions

In the context of this article the terms block element and inline element refer to elements with the CSS property display set to block/inline (explicitly or by browser preset) and not block or inline elements as referred to in html. (E.g. in this article and in CSS a list-item can be an inline or a block element while in html it is always a block element.) Unless indicated otherwise a div is always a block element, spans and images are inline elements.

Elements with layout are colored blue, elements without layout are colored pink. Images always have layout.

Example

This is pretty straightforward: Create a div, give it a relatively big font-size so you can see what's going on, throw in an inline element like an image... that's all. Fig. 1 is a live demo of the decribed setting, while Fig. 2 shows a FF screenshot of the correct rendering.

Dance the collapse

United

Things aren't always as bad. Let's say the image is acompanied by a glyph, pre or post does not matter (Figs. 3/4). Now, everythings in order: The glyph and the image get placed on the baseline of the linebox created inside the containing div.

Falling Apart

Ok, so who cares if something works out allright in IE? Let's force a line-break between the glyph and the image (Figs. 5/6). Ah... that's more like it... The glyph is positioned properly but the image is treated like a block element again. Note that this behaviour does not depend on explicitly forcing the linebreak (e.g. with <br>), reducing the container size would normally trigger the bug as well, but IE's holy-union bug LINK prevents that from happening if the image preceeds the glyph as in Fig. 4.

Fix

So how to fix this? Well, fortunately IE thinks trailing white space is a welcome opportunity to create a line box. As annoying as this behaviour is in a list, in this case it helps fix the bug. All we have to do is insert white space after the inline element that is rendered incorrectly. IE creates the linebox, aligns the inline element with/on the baseline and all is well (Fig. 7).

Within the inline element, make sure to remove any white space preceeding (red) the bug-fixing white space (green) as otherwise the second white space is being ignored (Fig. 8) due to CSS' white space collapsing behaviour.

Balancing the universe

In IE there's a nice symmetry between list-items and other block elements: While in list-items block elements are in some respect being treated as inline elements, the opposite is true for other block elements. The fix for the collapsing block box bug is cause for the list-item white space bug and what fixes the white space bug prevents the fix for the collapsing block bug from working. Beautiful.