Design for the beast.
Beyond the serene waters of Firefox, beyond the vast fertile plains of Safari, farther even than the citadel of Opera and the murky swamps of Internet Explorer 7, there lurks a beast–one that will take your best website designs, devour them, and leave nothing behind but a smoldering slag heap. It will reduce you to a blubbering pile as hours of your best work disappear into it’s gaping maw.
This beast is Internet Explorer 6.
A Plan of Attack
Everyone has their own recommendations for developing for Internet Explorer 6. Some start with a webpage that works in IE6, then testing it with more modern browsers. This is fundamentally backwards. Doing your initial coding with the goal of IE6 compatibility doesn’t encourage clean markup, valid code, or CSS best-practices. IE6 is the problem, so why saddle other browsers with code best suited for IE6?
We start our IE6-safe design by ignoring it. I personally am a strong advocate of using a reset stylesheet as the basis for your design; these remove inconsistencies in defaults between browsers and help ensure more consistent cross-browser rending. I start testing in Firefox, my preferred browser; feel free to use Safari, Opera, or even Internet Explorer 7 according to your preference. Once your site is perfect in your browser of choice (and you did remember to test in different resolutions and at different font sizes, didn’t you?), move to one of the other browsers. Test, tweak your CSS as needed, then make sure you didn’t break anything in your original browser. Keep iterating through this process until you’ve gone through all four browsers. Although any order is fine, I’ve had the best luck going from Firefox to Internet Explorer 7 to Safari to Opera; chances are good that by the time you have any two browsers done, the remaining two will require minor changes (if any) to work.
Once you’ve run the browser gauntlet, it’s time to validate your CSS. While there’s been some debate about how important validation actually is for CSS, it’s still generally considered best practice. Even if you end up without valid CSS when all is said and done, the CSS validator can help alert you to potential pitfalls along the way, including the bone-headed typos that I’m so apt to make. (Note, here, that there’s a difference between valid code and validating code; CSS vendor extensions like -moz-border-radius are valid according to the W3C, but will throw errors in their validator. So keep in mind what the rules are, when to bend them, and when to break them.)
At this point we’ve dealt with everything but Internet Explorer 6, creating a stylesheet that works in modern browsers. Now we’re going to give IE6 (and below) it’s very own stylesheet using Microsoft’s proprietary conditional comments (plain English explanation here):
<!--[if lte IE 6]>
<style type="text/css" src="ie.css" mce_src="ie.css" />
<![endif]-->
What’s going on? The more astute of you may notice that we have inside what is actually a special HTML comment a link to a file called ie.css. Because of Internet Explorer’s support for conditional comments, it will read what’s inside the comment as regular HTML if it’s version 6 or earlier (the lte 6 part of the equation); everything else will ignore it (because, after all, it’s just a comment). Now we can dump IE6-specific hacks in their by the truckload and not have them effect other browsers. Not only that, because the code is actually in a comment, our page’s CSS will still validate (if we decide we’re into that sort of thing), no matter what kind of dirty, dirty things we have to do in there.
Know Your CSS Hacks
So what kinds of things are you going to need to put in your ie.css file? There are entire sites dedicated to Internet Explorer 6 bugs and workarounds; no point in rehashing them all here. Two that you’re sure to run into are the box model and the ever-mysterious hasLayout; the former can be fixed by adjusting width and height relative to padding and margin in your ie.css file, the latter can usually be fixed with the simple addition of the proprietary ‘zoom: 1;’ to the offending elements.
Another major issue is that Internet Explorer 6 and below don’t support lovely transparent PNGs. There are a number of fixes for this problem, none of which are entirely satisfactory, since they rely on CPU-intensive Direct X filters and JavaScript. Often times I’ll swap out my PNGs for GIFs in the ie.css file.
Testing On Any Platform
Of course, you’re going to need to test all of this somehow. At this point, very (very) few designers and developers have Internet Explorer 6 as their primary browser, so we’re going to have to get our hands on it somehow in order to see how all of this is looking. Luckily, we’ve got some options.
Web-based
Competitors: BrowserShots (free, recommended), BrowserCam, IE NetRenderer (free), Litmus, IE Capture (free)
Advantages: no setup, cheap or free, test multiple versions of Internet Explorer at a time, works on any operating system
Disadvantages: no interaction (can’t test JavaScript or hover effects), slow refreshes makes squashing bugs slow
Virtual Machine Based
Competitors: VMWare Player (free), VMWare Fusion, Microsoft Virtual PC (free, recommended)
Advantages: comprehensive interactive testing, real-time
Disadvantages: time-intensive initial setup, requires powerful computer and extra HD space
Multiple IEs
Advantages: real-time testing, easy setup
Disadvantages: Windows-only (or Wine or Parallels?), unreliable version reporting (conditional comments don’t always fire correctly), JavaScript and Active X issues
Final Thoughts
As designers we’d all love nothing more than to ignore Internet Explorer 6 and pretend it’s not there. But depending on your site, 15-50% of your users will be using IE6, so do so at your own peril. We’ve only scratched the surface here, focusing specifically on CSS. However, the iterative browser testing described is equally effective for things like JavaScript development.
Best of luck.
