Zenscope Studio

Targeting and Managing CSS Hacks

Thoughts on CSS validation vary. I’m not a “validation nazi,” but I find that starting with valid code makes troubleshooting later on much easier. Unfortunately, the browsers don’t always agree. Internet Explorer is notorious for its poor interpretation of the CSS specification, but other browsers have their own problems.

CSS hacks and work-arounds are a necessary evil of client-side website development, and on complex sites they can really start to pile up. This causes long-term maintenance headaches as new browser versions are released and old ones fall out of use. To keep your sanity, you need a strategy for targeting and maintaining your browser-specific CSS.

Targeting Hacks for IE

If you’re only hacking to please IE, Microsoft has provided a handy work-around to hide code from other browsers and from certain versions of their own browser. Called “conditional comments,” these things look just like regular comments to other browsers. Anything within them is ignored, but their peculiar syntax is picked up by IE. Here’s an example of a hack-filled stylesheet that’s visible only to IE6:

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

You can learn all about the CC syntax from this article in SitePoint’s CSS Reference.

There are various tricks and techniques to using conditional comments effectively. Microsoft recommends targeting hacks as narrowly as possible to avoid compatibility problems with future releases. For example, a stylesheet aimed at IE7 should use if IE 7 not if gt IE 6. The later could cause problems by applying the hacks to IE8, which is supposed to be far more compliant with the CSS specification.

Targeting Hacks for Other Browsers

No web browser is 100% perfect in its interpretation of the CSS standard. Sometimes (but not often) you’ll need to target a hack or work-around at a non-IE browser.

There are all kinds of CSS filters that target particular browsers and browser versions.¹ Use these to pick and choose which rules to apply where, and confine your hacks to a separate stylesheet for each browser or browser version. You can then use @import to bring the hacks into the main CSS file. Sometimes you can even filter out browsers using the @import statement itself.²

For more information on using @import to manage CSS hacks, see Molly Holzschlag’s article on long-term CSS hack management.

The Maintenance Advantage of Hack Separation

The advantage of separating your hacks like this is maintainability. You know which files contain invalid or hacked-up code, and you can find and edit that code easily. No more searching endlessly through a thousand-line CSS file for that Safari 2.x hack that you added last year—just open up the hack_Safari2.css file and get to work.

When the market share of an old browser version finally drops low enough that it’s no longer a concern, just remove its @import statement from the master stylesheet or the conditional comment code from your site templates. Delete the corresponding file, and you’re done. Easy!

Share Your Hack-tastic Tips

Do you have a favorite strategy for managing CSS hacks in your projects? Leave a comment below to share your tips.

Comments (3 so far)

1. I usually keep IE6/7 hacks in the same ie.css file because inside it, I can keep IE6 and IE7 hacks separated, if necessary, by using the * html hack to target IE6 only. So, in the stylesheet, there are some rules/hacks that applies to both versions of IE, and some that only applies to IE6.

   I call the stylesheet using CC, like this:

   <!—[if lte IE 7]>
<link rel=“stylesheet” href=”/css/ie.css” type=“text/css” media=“screen” />
<![endif]—>

   “lte” means “less than or equal”, so this stylesheet is only applied to IE7 or less (btw, I’ve dropped any kind of support for versions prior to IE6).

   Finally, in the main CSS file, in each rule that is overriden by ie.css, I add something like this: /* extra rules added on ie.css */

   PS: mmmm, some Textile isn’t working here. I left the Textile mark-up so you can replace it with proper HTML.

   by Maniquí on Apr 8, 02:31 pm

2. Thanks for stopping by, Maniquí. These tips will give the most benefit with larger sites or complex layouts. Outside those areas, all that separation might be more trouble than it’s worth.

   I do it mostly to keep things tidy and save time when changes are needed. There are almost as many philosophies about organizing CSS code as their are people who write it—the trick is to find the best approach for you and your workflow.

   P.S. Sorry for the trouble you had with comment formatting. That’s just Textpattern applying “restricted” Textile to comments. WordPress does something similar by stripping out any HTML tags that aren’t allowed.

   by Adam Messinger on Apr 8, 10:55 pm

3. I have been developing websites for years and have never needed to use IE conditional comments. IE 6, IE 7, Firefox, and Safari constitute the major web browsers in use today. In the last 3 years specifically, I have contracted for many agencies, design shops, and medium/large businesses, and have never had a request to develop for anything below IE 6. Not enough people use 5.5 or below to justify the extra development time.

   I have implemented some extremely difficult designs, and 99% of the time, if the CSS is written correctly my layout looks identical in IE 7, Firefox, and Safai 2.0+. IE 6, however, presents numerous challenges. Fortunately, these are easily overcome with the direct descendent hack.

   Here’s how it works. Say you have an absolutely positioned div that looks perfect in FF, but renders a few pixels too high in IE 6. To overcome this, you would write 2 styles:

   /* style for IE 6 */

   #div1{ position: absolute; top: 15px;}

   /* styes for FF, Safari, and IE 7 */
   html > body #div1{ top: 17px;}

   And there you have it. Basically, all browsers read the first specification, which sets the div’s top at 15px. IE 6 does not understand the html > body #div1 declaration, so it just skips over it. However, IE 7, FF, and Safari do, so they reset top to 17px.

   I’m not saying that conditional comments have no place; many people rely on them and that’s fine. I’ve just worked on/inherited sites that rely too heavily on them, and they can be a nightmare to work on..

   by annonymous on May 12, 11:14 pm

Comment Subscription Feed

Got Something to Say?

Join the discussion by adding your comment:

Required Fields Marked With *

Name* Remember

E-Mail* (never published)

Website

Comment*

Tip: format your comment with Textile
(Textile Help)