Many thanks to Parakey for their Firebug Firefox Extension and to Opera Software for their Opera Dragonfly without which this CSS study wouldn’t have been possible.
If you’re an experienced web interface coder like me, the kind of guy who spent several years doing more than just toying around with HTML and CSS, you know that mastering these is pretty close to arcane magic. When using standards-compliant browsers, the CSS box model might not look logical. A lot of times I have faced issues where I thought the specifications were simply screwed up, but they are not. The real issue lies within the default CSS values established as standard.
It’s the real part that’s screwed up, but fortunately it’s easy to fix it and make it work the way it apparently should. The trick is to overwrite the defaults with your CSS style sheet. One marvel of specifying a higher than average amount of CSS rules is that even browsers like Internet Explorer 7 will end up displaying your web site correctly because a major problem in web standards is the default rule set. Hence, we’re essentially going to overwrite these defaults here.
Let’s start by breaking down this sample code:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>CSS Box Model Test</title>
<style type="text/css">
.div01
{
width:150px;
height:150px;
background-color:blue;
}
.div02
{
width:150px;
height:150px;
background-color:green;
}
</style>
</head>
<body>
<div class="div01"></div>
<div class="div02"></div>
</body>
</html>
This perfectly valid HTML 5 code will produce a blue and a green square like this:
What’s important to notice here is how the defaults specify a margin of 8px all around the body element. These defaults are what make HTML easy and very much helped its success. It avoids us having to specify tons of display properties. However, simplicity is always at the cost of control. Hence, designing very complex CSS layouts might result in a few headaches linked to surprise default values that weren’t expected. Unlike what we tend to think, most padding and margin values actually don’t default to 0.
To show what I mean, change the div02 to this:
<div class="div02">
<h1>H1</h1>
</div>
And you get:
Take note here that we did not provide any padding or margin information to any of the squares for them to move down like this. If you see this in one of your complex designs, you might end up searching a complete afternoon for some discrepancies in your div blocks. The margin is actually on neither squares, those default to the expected 0px margin; it’s on the h1.
The problem lies in common mistakes made with the W3C Box Model, which differs quite a lot from the traditional box model older web developers might be used to. Quirksmode.org explains it very well.
Firebug can also give us insight at how the margin affects the result:
This is where it gets tricky though. The width of any text element like our h1 is predefined to fill its parent container from left to right. Our h1′s width is thus 150px. The height of any text element is predefined based on the font. In this case, it’s 36 px. This is shown by the green highlight around the h1. Our h1 also has a predefined top and bottom margin so to make it stand from the rest of the text. This is natural and removing this margin makes your text look cramped, but this margin is exactly where all the problem is.
In the W3C Box Model, there exists three ays to define extra spacing between elements; padding, borders and margins. The padding comes first, and is then followed by any border, and lastly by the margin. All of these elements exist outside the element’s width and height, meaning a 20px padding and a 100px width will equal a total width of 120px.
The border is self-explanatory, but the difference between a padding and a margin is more subtle and difficult to grasp. Layed down on paper though, it’s actually quite simple.
The margin is transparent and lies outside the border of an element. Even if the element has a border of 0px, it is still outside the border. A margin does not acquire the background color of an element.
The padding on the other hand lies between the border and the box of an element, or inside the border if you want. Hence, a lot of people like to call the padding a margin but for the an element’s content instead of the box. A padding acquires the background color of an element because it is part of the content (what’s within the border).
If we base ourself on the previously explained box model, then logically the h1 should be entirely contained within our green box, but it is not so. Why? Because the standards people screwed up. Wait, wait, you’re thinking, is this guy serious? Well yes I am, and all the evidence is there to prove it. In fact, a lot of modifications we can do to the code clearly demonstrate how every single browser manufacturer, probably due to the people who made the ACID tests, communally screwed up on this and manufactured a giant bug.
To understand how this bug works, let’s first look at what the result should look like:
To obtain the following, I replaced the 21px margin with a 21px padding like so:
h1
{
margin-top:0px;
padding-top:21px;
}
Doing so does provide a quick fix, but not in the event you’d be using a background for your h1 element. While such an occurence is rare, major web sites like Engadget use this background technique to make their links’ roll-overs. Replacing the margin with a padding would completely screw up their design by incurring a huge extra highlight on the text like so:
The real way to circumvent the problem is to use the box model in a way that doesn’t include the bug. Weirdly enough, this is quite easy and proves that it really is a bug. Simply add any padding or border to the affected box and voila, problem solved:
.div02
{
width:150px;
height:150px;
background-color:green;
padding-top:1px;
}
But just for the sake of it, I’ve made another example that demonstrates how this can only be a bug.
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>CSS Box Model Test</title>
<style type="text/css">
.div01
{
width:150px;
height:150px;
background-color:blue;
}
.div02
{
width:150px;
height:150px;
background-color:green;
color:white;
}
.div03
{
width:150px;
height:150px;
background-color:red;
}
.div04
{
width:100px;
height:100px;
background-color:yellow;
}
.div05
{
width:150px;
height:150px;
background-color:black;
}
.div06
{
width:100px;
height:100px;
background-color:yellow;
position:relative;
top:16px;
}
.div07
{
width:150px;
height:150px;
background-color:blue;
}
.div08
{
width:150px;
height:150px;
background-color:green;
color:white;
margin-top:20px;
}
.div09
{
width:300px;
height:400px;
background-color:red;
}
.div10
{
width:200px;
height:140px;
background-color:yellow;
}
</style>
</head>
<body>
<div></div>
<div>
<p>Paragraphs are also affected</p>
</div>
<div>
<div><p>This…</p></div>
</div>
<div>
<div><p style="margin-top:0px;">should technically do this.</p></div>
</div>
<div></div>
<div>Any block following another block with a margin is affected. This text doesn't have any margin.<br>
The box does.</div>
<div>
<div><p>The first block remains intact or influences the one on the previous level if it exists as it is in this scenario.</p></div>
<div><p>The second block follows the bug partern.</p></div>
</div>
</body>
</html>
Since it is possible to reproduce this bug at all times under specific conditions, it is clear this is a manufactured bug that has been hidden away as standard. If someone believes this is not a bug and that there is a logical explanation to this behavior, please post a comment and explain! (One from Håkon Wium Lie would be appreciated)
