minimal design

Little disclaimer before I get into the meat of the subject: You should develop on your favorite Standards compliant browser (I use Safari because I’m an Apple fanboy, but Firefox would probably be the “reference”) and make sure your CSS works consistently across all Standards compliant browsers (Firefox, Safari, and Opera would be a good start) before you start adding any sorts of hacks… You should also try to understand the box model and most IE quirks in order to set things up in a way that will keep IE hacks to a minimum (for instance, avoiding specific width declaration with padding on container blocks when possible will minimize box model inconsistencies…). That said, in some cases, for instance PNG transparency, you just have to add IE specific declarations to your CSS.

About conditional comments

Conditional comments allow you to target specific CSS declarations to just Internet Explorer. They’re proprietary to Win IE and will be interpreted as a regular HTML comment to any other browser. For detailed implementation information and code examples, check out the excellent quirksmode’s article on the subject. What I want to talk about here is why using conditional comments is a good way to workaround the multitude of limitations that you’re bound to run into when dealing with Windows Internet Explorer’s CSS implementation.

How to use conditional comments

It’s very straight forward but there’s a little catch that some people seem to miss. Here’s the generic syntax:

<!--[if IE 6]>
    <link href="ie6.css" rel="stylesheet" type="text/css" media="screen" />
<![endif]-->

So far so good. The ie6.css file will only be seen by IE 6, all other browsers will treat it as a regular comment. The “little catch” I mentioned above that a few people seem to miss is that you shouldn’t duplicated your CSS files but instead override the few properties that need to be adjusted to accommodate IE shortcomings. Otherwise, any modifications or updates will become tedious and prone to errors. The easy way to do that is to import your ie6.css file after your main CSS file in your HTML and only write the few additional declarations needed for IE in your IE specific CSS file. So the HTML looks something like this:

<link href="main.css" rel="stylesheet" type="text/css" media="screen" />
<!--[if IE 6]>
    <link href="ie6.css" rel="stylesheet" type="text/css" media="screen" />
<![endif]-->

And, for instance, in your main.css file you’d have:

* {
    margin: 0;
    padding: 0;
}
body {
    width: 100%;
    background-color: #000;
    font: .7em/1.5em arial, sans-serif;
    text-align: center;
}
.wrap {
    position: relative;
    min-width: 980px;
    max-width: 1400px;
    margin: 0 auto;
    text-align: left;
}

while in your ie6.css file, you’d just have:

.wrap {
    width: expression(document.body.clientWidth < 985 ? "980px" : "100%" );
}

No need to rewrite all the other stuff since IE 6 will pick it up from the main.css file. All we need in that file is a way to emulate the min-width and max-width that IE doesn’t understand.

If you use your conditional comments that way, those IE specific CSS files shouldn’t be longer than 20 lines in most cases.

About CSS hacks

Another popular way to serve IE specific CSS is to use CSS hacks (position is everything is a good place to learn about CSS hacks if you don’t know about them). But most people using CSS hacks instead of conditional comments just don’t know about them or don’t understand how to use them.

Why conditional comments are better than CSS hacks

Forward Compatibility

CSS hacks rely on browser’s bugs whereas conditional comments are a deliberate feature created by Microsoft. No other browser implement them and it’s safe to assume that even if they do some day (highly unlikely) there’s no way they would recognize [if IE 6] and read the content… That means conditional comments are future proof whereas hacks are not. Here are couple of good examples of CSS hacks’ lack of forward compatibility:

• Position is everything homepage warning: “most of the demos in this site employ the Holly hack to work correctly in IE, but now IE7 fails to read the old star-html hack which was the vehicle for feeding the Holly hack hasLayout fix. Further, IE7 cannot be shown a small height to trigger hasLayout as has been customary. These changes require that modifications be made for the demos to work correctly […] As time permits we will be correcting all the pages.”
• Microsoft itself recommends you stop using CSS hacks

This forward compatibility issue itself is more than enough to justify the use of conditional comments over CSS hacks, but there’s more…

Reduced Bandwidth

All the extra code necessary for CSS hacks to work have to be downloaded by all browsers that visit the site. With conditional comments, only the specific browser that needs the extra CSS will download it.

Cleaner Code

Using conditional comments, your “base” CSS stays clean of any proprietary IE filters and cryptic code that means nothing unless you’re already familiar with the specific hack used. It makes it easier to understand the code and collaborate with other programmers. It also reduces the amount of explanation/commenting needed.

Easier QA Testing

If you find a bug later in the development or need to add compatibility to an older IE version (like IE 5.5), by modifying only the IE specific file, you won’t have to test all the other browsers again. With hacks, since they’re read by every browser, you would have to make sure it doesn’t brake any of them.

Conclusion

I actually don’t use conditional comments myself because I prefer my own solution, but I just read this really ill-informed article and wanted to help people new to CSS realize that they’re better off using conditional comments than CSS hacks.

I hope it helps!