Dealing with Internet Explorer is a fact of web design, and it isn’t going to go away anytime soon.
If not for some of the differences in the way IE6 and IE7 handle certain areas of CSS (whether it be margin bugs, float bugs, or other problems), CSS development would be so much easier.
Of course, as I’ve said in past articles on this website and others, I believe IE-only styles can be kept to a bare minimum, and in some cases you may not need any, but it’s unlikely that developers will end up so fortunate. So how do you divide your IE-only CSS styles? The options we have are as follows:
Option #1
A single IE-only stylesheet inside of a conditional comment; inside that file, different versions of IE are targeted with hacks.
Drawbacks to #1
- Every version of IE will load the extra styles, even the unused ones
- Potentially adds an extra HTTP request
- Changing something in the main stylesheet may require that you hunt down IE-only styles in a separate file
Benefits to #1
- IE styles are in one file, so they’re easy to maintain
Option #2
Multiple IE-only stylesheets inside conditionals, each targeting a different version of IE.
Drawbacks to #2
- Changing something in the main stylesheet may require that you hunt down IE-only styles in as many as 2 or more extra files
Benefits to #2
- No unnecessary HTTP requests
- No unnecessary lines of code loaded in the main stylesheet
Option #3
A single stylesheet that targets all browser, but within that stylesheet, IE-only hacks are present.
Drawbacks to #3
- Unnecessary lines of code are loaded for all browsers
- Your main stylesheet will not validate (thanks to comment from Jeremy Carlson for pointing this out)
Benefits to #3
- No extra HTTP requests
- No need to open multiple CSS files to adjust something that’s hacked for IE
Option #4
One or more JavaScript files inside of conditional comments that target different versions of IE, dynamically adding or removing styles and/or class names.
Drawbacks to #4
- IE Browsers without scripting enabled will not see the corrected CSS
- A slow loading script could cause the styles to be applied late, making the layout temporarily look awkward
- Will be complicated to maintain, and could also require extra IE-only stylesheets, adding to the page bloat and slowness
Benefits to #4
- Could work on buggy elements that won’t behave with pure CSS (I’ve seen this happen and have used this method when time/budget was limited and the CSS was too messy to deal with normally)
Option #5
Ignore IE.
Drawbacks to #5
- Locking out a significant portion of your potential traffic/sales
- Client screaming at you because the website looks like crap in IE
Benefits to #5
- Only one hack-less stylesheet to maintain
- Peace of mind (but short-lived because of the screaming client)
Conclusion
In most cases, you’ll be using option #2 (multiple conditionals that target different versions of IE). But don’t rule out using #3. In situations where you’ve only got 2 or 3 lines of CSS to target a single version of IE, I think the best option is to just put those extra styles in the main stylesheet and allow it to load for every browser.
Remember that for most client projects, Internet Explorer is the most used browser. If you’re adding multiple extra files for all those users, that’s more HTTP requests, and so you’re making the pages unnecessarily slow for most of your users. I think a few lines of CSS in the main stylesheet is much better than adding one or more extra HTTP requests.
Feel free to offer your thoughts if there are any benefits/drawbacks (or even methods) I haven’t mentioned.
Thank for sharing.
I appreciate your tutorial. This will make it a lot easier for me the next time I do a website.
Huh….I thought I was the odd man out. I say this because you are saying not to rule out #3. Which I personally have no problem doing, but I’m curious why you did not mention the drawback of not validating. As soon as you use the _ to target IE6, kill validation goodbye. I will assume the other hacks I know to target IE7 or 8 will also make validation impossible.
I think that by knowing what is possible and what isn’t and knowing about the IE bugs, one could easily write a single stylesheet without hack.
Also, I would never understand the validating CSS issue. Why the hell would you want to validate it? I like many of the features that are coming with CSS3 and many clients do so, but it wont validate while using them. The idea of progressive enhancement is nice :) and people also like it.
Your site wont run fast if your CSS is validated by the community or the regulators. It will run faster because you use less images for rounded corners, and less JS to make IE6 responds like the newer versions, and not to mention adequate programming underneath all visuals.
Please if you can explain to me why validating CSS is so important for you?
I second the comment by Jeremy, not only because it breaks validation.
The biggest “problem” with CSS hacks (like underscore and star hack) is the fact that not everyone knows when and how they apply. Especially on projects where multiple developers and non-coders (like designers) should be able to read and write the stylesheets it’s a big pain to understand the hacks.
By splitting the code in specific files everyone understand when and how the styles apply and and is easier while debugging in different browsers (just open the stylesheet for the browser and make changes there only).
Your note about CSS3 and JS is also a bit bold… When I build a design I make sure it works, even without the fancy CSS3 and JS (or any CSS and images for that matter). I always make a default stylesheet, a sheet for the different browsers (by option #2) and apply CSS3 only when the browser supports it (checked by JS).
About validation: I usually don’t use it, but can be useful for debugging and to show of to visitors that you know how to code.
I can’t fully agree with you. Web sites are usually created for specific auditory. When designing it, designer keep that in mind, or I keep that in mind.
But, when coding, sometimes usually when coding forms, rules has to be broken in order to get better result.
Current validation rules are old and in some cases do not apply to our vastly growing development medium.
As I’ve said before in other places, hacks are almost unnecessary, especially if you know where bugs might show up. Oh and RTFM :) w3.org has all the information about how to code and why to code that way (about html/css)
I use conditionnal comments to add a class to the body, it’s still valid and the hacks are easier to read in the stylesheets :
<!–[if IE 6]>
<body class="ie6">
<![endif]–>
Jeremy,
That’s actually a good point, I do consider lack of CSS validation a small drawback, so I will add that to the article as a small correction.
Two reasons that I didn’t really think about validation in this piece is that I was looking more at how the styles would affect workflow and future maintenance (firstly). And also, when you target IE6, you can use the star-html hack, which validates just fine. Most IE hacks will be for IE6. (In fact, 99% of mine are for IE6, so my styles pretty much always validate outside of CSS3 stuff.)
I personally use #2, simply because I like the clean separation between the different versions of IE, although over the last couple of years, as I’ve gotten better at front-end dev I’ve found that my IE stylesheet have less and less in them.
An IE png fix here, a tweak to a bug or two in IE7, and in general my IE8 sheet is empty.
So it’s been tempting to lump all the styles into the main sheet, but keeping them separate just makes the site feel better constructed. And because of the small amount of CSS in those files I don’t find changes to them a chore at all.
@Jeremy & Martin
I occasionally validate my CSS, when I remember to, but I think I should do it more. Browsers are a lot more forgiving of CSS errors than they are HTML ones, and that’s probably made me a bit lazy.
But not only does validation serve to confirm that I’ve done things properly, it’s also a very good way of finding developer-caused bugs in html and css – it’s usually my first port of call when something’s not working right.
At the end of the day though validation is all about standards. And standards have made the web better – remember the blink and marquee tags? So don’t criticise someone for wanting to follow them.
I’m not saying that using CSS3 properties and _ or * hacks are necessarily going to ruin things, but it’s the principle that’s important. Standards lead to a more consistent web landscape which at the end of the day is better for developers, clients and most importantly, the user.
/my 2p
I use a variation on Option 1.
Use conditionals to wrap the site in an extra div. Leaves you with only one stylesheet.
<!–[if IE 6]><![endif]–>
<!–[if IE 7]><![endif]–>
<!–[if IE 8]><![endif]–>
Site Html
<!–[if lte IE 8]><![endif]–>
I don’t like using css hacks like * and _ to target browsers.
But on a whole I think it is better to adjust the html ( add a few extra html ) and
get it to work in IE6,7,8. In terms of CSS3 I don’t like the fact a lot of people are using javascript hacks to get things right in older browsers instead of letting things gracefully degrade. Just seems lazy.
I’ve been trying a more detailed version if what JB said that I am pretty sure I got from Paul Irish somewhere:
<!–
<!–
The benefits being, only IE get’s the extra ie.css file, 1 ie css file to look through for changes and there are no hacks just class qualifiers:
.ie7 #id .class,
.ie6 #id .class { what: ever; }
The downside is of course all ie users get the extra request, even if say in ie8 there was only rule. This is offset by the usually relative small size of the css file. I am very pleased Microsoft added the ability to target the browsers like this though, older Firefox/Safari browsers are a much more difficult problem to deal with.
Big AB
Whoops,
Should’a known that was going to happen.
<!–[if IE]><!–>
<link rel=”stylesheet” href=”ie.css” type=”text/css” />
<!–<![endif]–>
</head>
<!–[if lt IE 7 ]> <body class=”ie ie6 no-js”> <![endif]–>
<!–[if IE 7 ]> <body class=”ie ie7 no-js”> <![endif]–>
<!–[if IE 8 ]> <body class=”ie ie8 no-js”> <![endif]–>
<!–[if IE 9 ]> <body class=”ie ie9 no-js”> <![endif]–>
<!–[if gt IE 9]> <body class=”ie no-js”> <![endif]–>
<!–[if !IE]><!–> <body class=”no-js”> <!–<![endif]–>
I’ve started using a variation of this, but I don’t put the IE rules in a separate sheet — I leave them in the main sheet. This way, all the rules are in one place, next to the “real rules,” easy to track down, plus there’s no extra HTTP request for IE. Yes, it makes the file size of the one sheet larger for everyone, but only by a tiny bit — I usually have very few IE rules. (And yes, I got this idea from Paul Irish at http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/)
Same here since I don’t want multiple files open when I’m coding the same thing. I also use divs rather than changing the whole body tag.
* html (ie6) and * + html (ie7) both validate fine.
I’m perfectly fine with option 5. End of story.
if you simply stop supporting IE6 you can eliminate 99% of every IE specific “hack.”
There will still be some parts where you will have to play with the layout or padding or margin, or something stupid like that in IE, and in that case option 1 or 2 is fine.
Depending on how many things I are being changed, and how drastic the changes, I’ll either go with everything together in style.IE.css, or add them in the header under a tag
I find the “reduce HTTP requests to a bare minimum” to be good advice, but often taken too far to gain a few extra bytes that in the end, don’t add up to much.
The average size of the IE specific stylesheet I’ve made is under 1KB, which will be downloaded instantly for anyone.
I also find it hypocritical to say reduce HTTP requests when a simple look at the source of this page shows 12 links to scripts, and style sheets.
A few months ago this site was loading about 20+ scripts/stylesheets, and I’ve reduced it to what it is now (around 8-12, depending on the browser). So, it’s not hypocritical at all, because I have “reduced” HTTP requests as I said in the article.
Not to mention that it’s not as important on a site like this. My advice on any article you read here or anywhere else is mainly for client work, where speed optimization is much more important.
Very useful post. I have bookmarked this post. Thanks for sharing.
Great article, thank you for sharing and the comments… good discussion… no doubt. Thanks JB and BigAB that’s some thing that I’ll be trying to do more often from now on.
Option 6: Use server-side scripting to determine which browser is in use and dynamically insert the correct stylesheet.
Drawbacks:
– Separate CSS files are needed
– Need to know how to program
Benefits:
– No extra HTTP requests
Option 7: Use serverside scripting to output CSS. Create a file like style.css.php and use code to display rules for specific browsers. Could parse a CSS file or run functions within to output rules.
Drawbacks:
– Need to know how to program
– More time spent testing/coding (possibly)
Benefits:
– Single HTTP request
– Easy setup once concept is understood
– Code can be used for multiple sites
Thanks for this. Isn’t it true, however, that server-side browser detection is not reliable? I’ve been told that a browser can be faked on the client side (through a registry change or something..?). Of course, I don’t know how many people would actually do that (if any), so your solution may be quite feasible.
Well explained, I think option is better if you develop a wordpress theme or something that finally someone else may modify the css, being in the same file will be easy for end user…
I Mean option 3!
The mission now, is to get IE6 to a 1% in 3 years and we are doing our best.
Great Article!
Appreciate the tutorial, makes for interesting reading. It’s handy having the drawbacks listed separately from the benefits. We normally use Option #2 to be honest.
Thanks.