FaeDubh

Most everyone designing for the web platform nowadays knows of the infamous site-compatibility issues when trying to please both Mozilla Firefox and Internet Explorer. Things can go horribly awry; while one would trust that the two most popular internet browsers would work to produce the same, harmonious site, that feeling will quickly be betrayed. Sometimes the disagreement will be due to your own error: if you forget to close a tag properly, IE might overlook it but FF would definitely alert you by rendering a completely misaligned page. If you don’t close them in the right order, FF will be out for your blood. If you don’t remember to disable a certain default trait in CSS (list-style, anyone?), FF will output it for your viewing (dis)convenience. In these cases, IE’s like the lenient parent, while FF is the strict one that you ultimately end up liking better because it forces you to be more attentive, more logical. But those problems are relatively minor and once you get into the right habits, can quickly become a memory. And then you’re in the clear, right? Because IE output = FF output = yay pretty page, right?
But alas, no. Because there are some problems that are not your fault, but a difference in the browser’s coding, that will result in a completely different product between the two browsers until you figure out a way to sidestep the problem. The one most relevant to web designers? The way FF handles margins vs. IE’s way. First let’s review what’s the difference between margins and padding: margins should control the spacing of the area around a block-level element, while padding should handle the spacing of the area within the element. Now let’s set up a situation:
Say you had a bordered box that was a designated 500 pixels, left aligned, that you wanted to have a margin of 10 pixels all around and padding of 5 pixels inside, around the text. Now, how will that show up in the two browsers?

• Internet Explorer will handle it the way you probably planned; margin controls the outside space, padding controls the inside space. As hard as it is for me to say this, IE does it logically.
• Firefox, on the other hand, will take the margin number and include it in the width count, so your border will now only be 500-2(10)= 480px wide, albeit with the 10px margin you wanted so badly. The padding may end up looking like IE, though if you have a background on this box, you’ll soon realize that it actually adds the padding to the width already stated to get you an even bigger box. And your box won’t look right; it’ll be stunted. After realizing the problem, you will want to cry.

From that point, you’ll have several options:

1. Ditch the whole margin idea and have a box crowded in by content,
2. Use an IE hack to handle IE’s appearance and then work on making the Firefox look good through any means neccessary,
3. Make a wrapper class that handles the margins (but doesn’t do much else), OR
4. Not specify the width, leaving that for the contained elements of the box to handle, in which case Firefox, in its warped little mind, handles margins like Internet Explorer.

Option 2 is (in my view) not really fixing the problem with what you’re given but stepping over the problem through a technical loophole. I’m not a big fan of hacks, really, and try to use them as little as possible, because I’m innately lazy and unwilling to change coding if a new version of IE comes out that negates the previous hack. However, they are useful and I’ve heard that there’s at least one hack that won’t ever be fixed and still lets you validate your CSS-see here about Conditional Comments. (On a side note, since it’ll only add the additional code if it detects IE, you can put in scrollbar stylings in the IE-only code and the main CSS file will still validate.)
Options 3 and 4 both work in generating the correct margining, so then it’s really up to you- 3 requires almost no thinking but extra code, while 4 needs some logical reorganizing to make sure it’s the proper width but needs minimal extra code. I personally started with option 3 but now I lean towards 4, because it seems more efficient if you know what to do, and it’s always a better idea to keep the number of classes to the required minimum. Either way, this problem is happily resolved.
But as you know, if you’re a pessimist like me, there’s always an irresolvable problem that makes you tear your hair out. With these two browsers, it’s the pixel-rounding difference. It bites when you might be dealing with decimal positions- absolute positioning sometimes (when you’re positioning it relative to the bottom), background positioning (with percents), inline block links with hover border effects, and fluid layouts. Positioning an element just right is a tricky business in this medium, and sometimes when you think it’s there, you’ll open up the other browser and you’ll see that it’s just one pixel off. One tiny, minuscule pixel that nevertheless, makes all the difference. You can see it in action here: Rounding Error Test. As that page says, since screens can only render full pixels, sometimes with percents there’s a need to round to a working pixel size, which can get the layout a little bit derailed. (And once again, apparently, Firefox is most likely to be at fault. Internet Explorer actually pulled through on this one.) The worst part? There’s no real way to fix it. So if that ever happens, I guess you’ll just have to cross your fingers and hope your visitors are smart enough to resize their windows to more optimal dimensions. Which, fortunately, most are, which shows that humans still do have the upper hand on machines sometimes.
Now, there are a myriad of other inconsistencies that make my head spin, but they’re way to numerous to fully detail here. If you really want to read up on these really minute, walking-the-fine-line-between-obsessive-compulsive-and-successful-webdesigner bugs, I’d recommend Position Is Everything.