cross-browser CSS woes @ johnofjack.com

The box-model problem

In my readings on CSS, I found this article giving a basic description of the box model in CSS. The explanation is okay but not great: it explains where the content, padding, border, and margin all lie in relation to a box element such as a div, but it leaves out the difference in handling box borders, paddings, and margins across major browsers. Specifically, IE 5.x for Windows handles them differently from other browsers and, given its market share, the differences should not be ignored--the difference in handling can break a page's layout for a large number of viewers. As such, I expect the information to be very relevant to any webmaster using CSS for layout, regardless of the size of the site being designed.

Padding trouble

Suppose you want to set up a page with two divs floating beside each other, one floated left and one right (they might be an original article and a translation, or a bit of text and its redaction, or any other two texts meant to contrast each other). In this case we'll have a div "poe" that's bordered in blue, for obvious reasons, and floated left with no clear; with div "austen" beside it in red, for contrast, floated right, also without a "clear." Both divs are set to a width of 45%. (The CSS to achieve this is very simple and is available here.)

Firefox believes the div (box) width refers to the width of the box's content; it expands the box as needed to fit the content. Therefore in Firefox a box with a specified width of 300 pixels, with a 5-pixel padding on either side, will in fact be 310 pixels wide.

Internet Explorer 5.x for Windows (and IE 6, if the doctype declaration is incomplete or has an error) believes the div width refers to the box itself and holds the box width as constant, putting padding inside it. So that same box as above will be 300 pixels wide, with 290 of it left inside for content.

Below are two screenshots taken from box-model.padding.html. The Firefox example looks wrong but is, as will be discussed later, actually conforming to W3C specs.

Firefox float/padding example

IE 5.x/win float/padding bug

Border trouble

Again, Firefox considers a box width to be the width of its content. A 300-pixel div with 5-pixel borders and no padding will be 310 pixels wide. In IE 5.x/win, it will be 300 pixels wide. (A 300-pixel div with 5-pixel borders and 5-pixel padding would be 320 pixels wide in Firefox but 300 pixels wide in IE, with a 280-pixel width inside for content).

Margin trouble

Perhaps unsurprisingly, the two browsers also do not agree about what to do with margins. IE 5.x/win doubles the left-margin on divs floated left (and also, though it's not covered in this article, apparently doubles the right margin on divs floated right).

On this example, the "poe" div has a left- and right-margin of 5% and a width of 40%; "austen" has the same width but left- and right-margins of 4% (the reason why is to show one example where even a slight difference in CSS can break a layout on different browsers--even a 1% change in margin makes the IE version appear much more as expected). (Source: CSS, HTML)

Firefox float/margin example

IE 5.x/win float/margin bug

"Correct" behavior

According to W3C specs, the width of an element is the width of its content, period. Padding and borders are not considered part of the width. Personally, I've never measured a box by its content. I tend to think it best to measure a box it by its actual closed dimensions (if the walls were extraordinarily thick, I might measure the inside rather than the outside but I think, on the whole, that that is the kind of thing that would show up on some military spec sheet under two headings: "internal dimensions" and "external dimensions"). This is one of the few standards I find somewhat illogical--the "box" metaphor is faulty, as boxes don't tend to expand to fit what's put inside them. Still, there's no point in arguing standards unless arguing them to the body that makes them. What is important is to understand the difference between browser behaviors--Internet Explorer 5.x/win does not comply with the W3C box-model specifications and most other browsers do. Ignoring the difference can result in serious (and ugly, headache-inducing) effects on CSS-based designs.

The doubling of margins on floating divs, in IE 5.x for Windows, is just odd. I can't think of any logical reason for the behavior; I think it is most likely a bug (though, because of the market share of IE 5.x/win, one worth knowing about).

Potential solutions

As mentioned above, having a full and accurate doctype declaration causes IE 6 for Windows and IE5 for Macs to use the W3C's box model (more information about that is available here). The doctype declaration has no effect on IE 5 for Windows; that browser just simply gets it wrong.

There are various "box-model hacks" for working around the browser differences; for instance, this commonly-referenced article recommends using a hack to feed IE5.x/win a different version of the CSS accordingly (the Tantek hack), a solution that quickly snowballs, as it causes adverse effects in other browsers. Down this path, other hacks are added to the Tantek hack to prevent those browsers from malfunctioning (the Tan Hack, the commented backslash hack), then more hacks added to that for yet other browsers (the Holly hack, the whole-honking-enchilada-with-a-side-of-black-beans-and-rice-and-extra-guacamole hack). The result is that the "hack" looks like more of a "kludge": it's messy; it's ever-expanding; it results in non-standard, non-validating CSS. In my opinion, it's similar to using browser-specific HTML tags to get a certain behavior--it achieves the desired effect, but it's short-sighted and it muddies the communal waters. It sets a bad example.

Another approach to these problems is just not to use left- and right-paddings and -margins on any div; the webmaster can use them instead on the elements within. Applying margins and/or paddings to each element within can be tedious or not, depending on the layout (the number of headings, blockquotes, ordered lists, unordered lists, etc.), but results in valid CSS and conforms to W3C standards.

--------

Note: this paper was written in 2006; I have not experimented with IE7 to see what CSS quirks it has, nor have I done extensive testing on later versions of Firefox (expecting, perhaps foolishly, no serious regressions in compatibility). It might be a good idea to do your own compatibility testing with IE7 and/or to search for documentations of its treatment of CSS.

--jj, August 04 2008.