Bruce Lawson’s personal site

(Last Updated on 7 August 2008)

7 August 2008: It’s three years since I wrote this, and the browser landscape has changed considerably. A rewritten 2008 remix version is published on the Opera developer network: Supporting IE with conditional comments—please go there rather than read the article here.

The IE development team are calling on people to clean up their CSS hacks that might fail when IE7 is released, so I thought I’d tell you about how I did this for an emergency design I did for a punter a couple of months ago.

My plan wasn’t primarily to future-proof the code, but to remove as many css hacks as possible, as I’d been contracted to rewrite a small brochure site very quickly (a few hours), and hand it over to another developer whose experience and skill were unknown to me. The end result was to remove all but one hack. Another side-effect is (I believe) much better structured, more maintainable and more logical code.

What CSS hacks do

CSS hacks allow web developers to send different rules to different browsers, usually (paradoxically) to make each browser’s rendering of the site look the same. This is generally necessary as Internet Explorer 5 and 6 have many bugs, so gets “good” rules wrong.

There are two types of CSS hacks:

• Parsing Error Hacks use the fact that browser “x” stops reading a rule when it sees some wierd combination of characters (like "}"), while browser “y” continues unvanquished and receives the subsequent good rules. The problem with these is that they’re utterly unintuitive because they’re pretty random. If they aren’t well commented, you’ll never guess what they do.
• Weak CSS Support Hacks use the fact that IE can’t support advanced css selectors, and uses those to feed a rule to an advanced browser. The problem with these is that IE7 is coming over the horizon, and it will understand these rules. There may or may not be a problem, but if you want to be sure that your site won’t break in IE7, you’d better do something about it.

There are now a gazillion documented CSS hacks, but one of the most common css hack is a box model hack to get over the broken box model in IE5. It’s a parsing error hack, most of which is to fool different browsers into seeing the hack or not. For example, all the voice family shennanigans is merely fooling IE5 not to read any more of the rule, so not overwrite its overly wide dimensions:


#buttocks{margin:0; padding: 0 15px;
width: 194px; /*IE 5.5 width - Tantek hack */
voice-family: ""}"";
voice-family:inherit;
width: 164px; /*real width*/ }
html>body #buttocks{
width:164px;}

The second rule (“html>body”) is a “Be Nice to Opera” rule, because Opera would also stop reading at the voice-family crap and inherit the 194px, which we don’t want because its box model is fine. IE<7 doesn’t understand the child selector, so doesn’t bother with the “hug Opera” rule. When IE7 is released, this won’t break, because although it will read the Opera rule, that’s the width it needed anyway, so no damage done.

Except to the sanity of the poor guy who comes after me, who’s got to maintain all this stuff. It also offends my purist’s soul, polluting the css like this. Given that all this is to overcome deficiencies in Internet Explorer, wouldn’t it be superlovelygorgeous if we could have a good, valid, hackless stylesheet and an extra one flagged as “Hey! IE5! this is for you!”? Well, we can, using use Conditional Comments.

How conditional comments work

These are html comments, with a marker so that IE parses them, and you can use them to enclose any html code – including the linking of a stylesheet. They were introduced in IE5 for Windows, so can’t be used to target previous versions of IE. The best thing is that, because these are html comments, they’re invisible to all other browsers, and they pass validation.

Here’s the syntax I use to feed rules to IE5:

<link rel="stylesheet" href="styles.css" type="text/css" />
<!--[if lt IE 6]>
<link rel="stylesheet" href="boxmodel.css" type="text/css" />
<![endif]-->


The main styles.css has this simple rule:
#buttocks{margin:0; padding: 0 15px;
width: 164px;} /*see boxmodel.css for IE5 override */

and boxmodel.css – which is only served to IE5 – overrides it thus:
#buttocks{width: 194px;} /*other rules in styles.css */

No confusing voice-family hacks or Be Nice to Opera rules! Huzzah!

IEbugs.css – correcting the main bugs and IE6 and earlier

A lot of css hacks are to feed rules to IE6 and below to compensate for the lack of many important features of modern web development, like PNG alpha transparency, CSS min-height and fixed positioning.

We can remove the hacks by calling a special override stylesheet called IEbugs.css for IE6 browsers or below, like this:

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


Simulating min-height

Suppose you have a box that should never be less than 100px tall – perhaps you have a 95px background image that you always want displayed, but you can’t predict the quantity of content. In a standards-compliant browser, you’d use min-height, which doesn’t work in versions of IE less than IE7.

To work around it, we add a rule specifying the height (which works the same as min-height should). So if the rule in the main stylesheet says #box {min-height:100px;} that should be supplemented in IEbugs by

#box {height:100px; overflow:visible;} /*simulate min-height */


Give GIFs to IE, PNGs to the good guys

People who are more design-oriented than I am have long used graphics in the PNG format for their layouts as it allows them much more flexibility and loveliness. Unfortunately, IE6 doesn’t do PNGs properly, so people have used another hack to send an image that’s a GIF to IE. Here’s an example, using the * html hack that only IE understands:

#lovely {background: url(lovely.png) no-repeat;}
* html #lovely {background: url(lovely.gif) no-repeat;}

IE7 can do PNGs properly, and it will not understand the * html rule, in which case, it will receive the PNG sent by the first rule: all well and good. But as this is a rule for pre-IE7 browsers, it would be better sent to the doghouse of IEbugs.css.

Once banished, it won’t need the * html prefix, as the stylesheet is only being sent to IE<7, and will overwrite the main rule. So the main stylesheet keeps #lovely {background: url(lovely.png)no-repeat;} and IEbugs.css adds

#lovely {background: url(lovely.gif) no-repeat;}


Stopping long words destroying layout

Contrary to spec, IE allows very long words to expand a box widthwards – which can then easily destroy a layout if other boxes are floated right. This is particularly dangerous in areas where content can’t be rigidly controlled and tested, such as where blog comments are displayed, as someone can accidentally (or maliciously!) enter a very long word and totally nuke your design.

There’s an IE-specific css extension that will fix this, but prevent validation. Personally, I’m happy to use non-validating IE-only tricks to correct IE’s bad behaviour, particularly outside of the main stylesheet. Your purist levels may differ, of course.

Add this rule to the box that holds blog comments (or do what I did, and just add it to the body tag):

body {word-wrap: break-word;}

(I don’t know if IE7 will clean up this bug, so this may be better in a stylesheet for all IE browsers – see below).

Advanced IE6 bugfixing

If your design requires the ability to hover over any element, rather than just the a tag as IE currently restricts you to, you can add the csshover behavior in the IEbugs stylesheet:

body { behavior:url("csshover.htc"); }


(You can even go the whole hog and simulate IE7 with Dean Edwards’ JavaScript library, using conditional comments to pull in a JavaScript library.)

Another potential reason for an IE.css that I haven’t yet researched thoroughly might be to add IE Layout to certain elements, which can help stop many IE6 rendering bugs.

IE.css – serving styles to all versions of IE

Another good use for conditional comments is to seperate IE-only extentions to the CSS spec, as they’ll stop your main styles.css from validating (and aren’t necessary in a non-IE browser, so why send them?).

Such extensions would be filters on images, or coloured scrollbars.

Here’s the code for the head of the page:

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

If you don’t need these extensions, or you don’t care that you have stuff in your main stylesheet that won’t validate (and, in a practical world, there are absolutely no negative side-effects if you have) you can just leave this in the main stylesheet, although I prefer to completely seperate it out.

IE/Mac: the new Netscape 4

Not being gorgeous enough to be allowed to use a Mac, I haven’t tested this, but add it for completeness. I’m told that conditional comments only work for IE/ Windows.

If you need to feed rules to IE/Mac (which they say is as moribund as Netscape 4), there are hacks available, but you should consider importing a seperate IEMac stylesheet in your html header and keeping all IE/Mac rules in there:

<style type="text/css">
@import("IEMac.css");
</style>

The formatting of the import must be exactly as above. (Hat-tip)

Alternatively, you can keep your html header clean and import a separate IE/Mac set of rules from your main stylesheet via Tantek’s IE5/Mac Band Pass Filter, which is made out of fairy dust:
/*\*//*/
  @import "ie5mac.css";
/**/

Update 24 October 2005: Martin Belam, of the bbc website, analysed the 30 million requests for the BBC homepage in September 2005, and found that IE/Mac was used four times as much as Firefox/Mac, so maybe it’s a little too early to write IE/Mac’s obituary if yours is a real-world site (rather than Web Geek site).

Get yer code on, baby

To recap, here’s all the code for your header (you probably won’t need all of it)

<link rel="stylesheet" href="styles.css" type="text/css" />
<!--[if IE]>
<link rel="stylesheet" href="IE.css" type="text/css" />
<![endif]-->
<!--[if lte IE 6]>
<link rel="stylesheet" href="IEbugs.css" type="text/css" />
<![endif]-->
<!--[if lt IE 6]>
<link rel="stylesheet" href="boxmodel.css" type="text/css" />
<![endif]-->
<style type="text/css">
@import("IEMac.css");
</style>


Minimising http requests

Each stylesheet pulled in requires an extra http request, which can slow things down because the http gnomes get tired easily. In order to minimise these, you can combine all IE-facing hacks into a single IE.css, but would still need a version of the box model hack in here so IE5 gets the wider box. To send 164px width to IE6, and 194 to IE5, we need the voice-family jiggery-pokery from before, but don’t need the Be Nice to Opera rule. Here’s the code:

#buttocks{width: 194px; /*IE 5.5 width - Tantek hack */
voice-family: ""}"";
voice-family:inherit;
width: 164px; /*real width*/ }


A testing Gotcha

If you’re using multiple test versions of IE, don’t freak out when it appears that your boxmodel.css hasn’t taken. Whichever version of IE you fire up for testing, the conditional comment parser always believes that you are using the latest version installed. For those who are comfortable editing the Registry (about as nerve-racking as doing the splits naked over a live lobster, in my opinion), there is a fix (Hat-tip Simon Pieters).

Using conditional comments to hide something from IE/ Win

(Update 14 Nov 05). Roger Johansson notes Lachlan Hunt’s method of hiding something advanced from IE/ Win:

<!--[if !IE]>-->
do something; IE will ignore this, other browsers parse it
<!--<![endif]-->

This validates fine.

Conclusion

Although I’ve no religious objection to css hacks, we all have to be aware that pretty soon, a big new browser is coming to market. It’s good development practice to modularise your code, especially as within a year of release, IE7 will be the biggest browser and the hacks for old IE will become less and less useful.

I personally find development a lot easier if I can develop for Firefox first, with a “clean” stylesheet. When things start to take a turn for the unexpected, the css validator is a useful diagnostic tool. This utility is compromised when the stylesheet is full of IE-facing hacks. So I like to get everything working for a modern browser, and only then apply the hacks, using conditional comments.

Whether you believe that serving different stuff to different browsers is philosophically valid or The Work of Satan and All His Minions that will result in The Destruction Of The Web is entirely up to you. You may also feel that conditional comments, being IE-specific, are worse than css hacks. So be it; that’s your right. I’m a pragmatic purist, and this methodology works for me.

So let’s see it then, Mr Wilson

It’s fantastic that Microsoft are listening to us, and communicating with us. But the time has come now to let us play with the new Standards-aware IE7 beta and see what’s hot and what’s not – and feed it back, politely and constructively, to the IE team so the program gets better.

When you should use hacks, and not Conditional Comments

I haven’t had occasion to use the techniques so brilliantly devised by Alex Robinson in his article “In search of the One True Layout”, but I’d never ever contemplate doing it without CSS hacks. It’s complex enough for a third party to maintain or amend without various chunks of it being lopped out into seperate files. (Is it IE7-proof?, I wonder as an aside).

The conditional comments technique works very well if you have a relatively set design for your site. If you have a skinnable site, with loads of alternate styles and a stylesheet switcher, you probably need to continue with your css hacks. And that’s OK; most of your hacks should work OK with IE7. (Though it would be nice to test them, eh Microsoft?)

However, I’m talking about super-skinnable, to the level of something like the Zen Garden where the whole page layout radically changes. For stylesheet switchers that play with fonts and colours (probably for accessibility reasons, like red ant design do), I’d still recommend Conditional Comments, because IE isn’t so broken that it requires seperate stylesheets to override font and background colour declarations.

I’m making a similar stylesheet switcher for punter at the moment, using conditional comments. And one day, when IE6 has gone the way of IE4, I’ll just remove the conditional comment and, with a satisfied smile and a spring in my step, I’ll quietly delete IEbugs.css from my server. One day ….

50 Responses to “ Future-proof your CSS with Conditional Comments ”

Leave a Reply