ie6 debugging

the golden rule

Since I stumbled onto the subject of ie6 anyway, let's take a little breather from 2009 and venture back into the past to see how the biggest browser of yesteryear should be handled. This article will reveal the golden rule of ie6 debugging and will also take a quick stroll past the different ways of organizing your ie6 debugging rules.

the golden rule of ie6 debugging

There are few web developers who haven't complained about ie6's behavior before, but there are also few web developers who realize that for the bigger part, ie6 can be forced into submission. Even though it fails to do a lot of things correctly, with a few nudges and kicks it does behave like all the other browsers (for supported css properties anyway). So let's take a look at how you should go about debugging your site in ie6.

There is a big difference between making a design look the same in ie6 and fixing ie6's css behavior. Many out there try to do the first thing. They start adjusting css values for widths, paddings, margins and whatnot, to make their design behave as it does in other browsers. While the end user won't notice the difference, this way of working is hardly flexible.

So rather than mend the design, it is better to simply force ie6 into submission. There are a couple of rules and fixes that will make ie6 behave like it should, which has the incredible benefit that late changes in your main stylesheet won't affect your ie6 fixes. If you simply mend a design, each change in the main stylesheet file might invalidate one of your fixes, making debugging even a bigger chore.

To illustrate this idea, simply consider the double margin bug in ie6. You can fix this by feeding ie6 a margin that is only half the size, or you can just add a display:inline to the floated element to make sure ie6 behaves. Whenever you change the initial margin in the main css, you can leave ie6 alone rather than keep adjusting the value separately. Extremely simple, but it's surprising how many people still stick with the mending method.

keep your debug css as clean as can be

There are several ways to go about ie6 debugging, ranging from clean to messy. And since ie6 is messy enough by itself, it's best to keep your debugging rules as clean as possible. What follows is a quick overview of the possible ways you can organize your ie6 fixes.

method 1: keep the design from breaking

This is without a doubt the dirtiest method of the bunch, but you still see it popping up from time to time. Rather than aim for mutual cross-browser rendering, you play around with css values to make it look okay-ish in all browsers. A typical example of this is playing around with the widths of input fields. They never quite match cross-browser, but as long as it doesn't break your design, the extra space in some browsers isn't a show stopper.

Needless to say, avoid this as much as possible.

method 2: adjust the css for ie6 inside the main css

* html .allContainer {width:73.85em;}

Using css hacks, you can target certain browser versions from your main css. This way you can, for example, feed ie6 a different width value compared to other browsers. This is quite helpful as you can easily fix a design to make it look the same in all browsers. The infamous * html hack is used for ie6, but there are many others.

Make sure though that you organize these rules in a separate section of your stylesheet, if not they will aid in turning your css file into a downright mess.

method 3: conditional comments

Rather than using browser specific hacks, it is much better to use conditional comments. These comments are only available for ie (which is a shame really), and refer to a css file that will only be loaded by browsers that test positively to a logical condition (the if statement). This way, you can centralize all hacks in a different css file without any dirty hacks, that will overrule the main css. Do make sure though that the browser-specific css files are included after the main css files, otherwise it won't do you much good.

Another thing to realize is that ie6 and ie7 share a fair portion of the same bugs. That's why I usually create one general ie css and one specific for ie6. With ie8 coming up though, this method is probably due for revision.

Sadly, if you're working on an already existing project, making use of conditional comments is not always possible, so even though this is definitely the preferred method, from time to time I still revert to method 2.

up next

In an upcoming article, I'll explain some of the clean and clear fixes for ie6 which can be applied without worry and which fix a whole lot of problems from the ground up, rather than mend the design in ie6. But for now, think twice about playing around with values and invest time in trying to find the real reason why ie is misbehaving. In a lot of cases, you can simply turn ie6 into a good boy with one harmless fix. Stay tuned.