K-U-H-N.net

Introduction

This is a bug that causes IE to ignore line-height settings on a block element containing an inline element with layout.

Affected Browsers

The bug affects IE6 and IE5.5 for all and IE7 for sub-normal line-heights. The bug has been fixed in IE8.

Trying to find a way to implement max-width behaviour in IE6-, I stumbled upon an Opera/IE7- bug concerning their shrink-wrap behaviour. Firefox 3, Safari 4 and Chrome 2 do not show this bug and it has also been fixed in IE8. The bug shows in Opera 9.64, feedback on earlier versions would be appreciated.

If we put a shrink-wrapped inner box (dark gray) with some content inside an outer box (light gray) with an explicit width set, the inner box will grow with its content until it reaches the content-edge of the outer box. At that point line-breaking or overflow is induced in the inner box. So far so good, but after a linebreak IE7- and Opera shrink the box to fit the text's width while all other aforementioned browsers dont't (See Figs. 1-3).

FF screenshot

Fig. 2

Opera screenshot

Fig. 3

Well, that can't be right... Let's have a look at the specs:

Calculation of the shrink-to-fit width is similar to calculating the width of a table cell using the automatic table layout algorithm. Roughly: calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur, and also calculate the preferred minimum width, e.g., by trying all possible line breaks. CSS 2.1 does not define the exact algorithm. Thirdly, find the available width: in this case, this is the width of the containing block minus the used values of 'margin-left', 'border-left-width', 'padding-left', 'padding-right', 'border-right-width', 'margin-right', and the widths of any relevant scroll bars.

Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).

Ok, what does that mean for our little example?

1. The preferred width is a lot longer than the outer box's width, as the text does not fit inside the box without a linebreak.
2. The available width is the width of the outer box.
3. The preferred minimum width, although not further specified, is definitely smaller than the outer box's width, as there is no word longer than the outer box's width.
4. The maximum of the preferred minimum width and the available width, is the available width (2 + 3).
5. The minimum of the available width and the preferred minimum width is the available width (1 + 2).

Therefore (4 + 5), the shrink-to-fit width is the available width.

In conclusion, though at first glance it may not seem so, IE7- and Opera are wrong.

As always, feedback is appreciated.

Introduction

Let's talk about lists... While there are many well documented bugs concerning lists in IE, there is one that I couldn't find much about. Basically, in list-items, IE treats block elements with layout like inline-block and in some respect like inline elements, which can cause various positioning and white space problems.

Affected Browsers

The bug affects IE7- and has been fixed in IE8.

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.