Today I saw a little post by Brian Cray “Target IE6 and IE7 with only 1 extra character in your CSS” which bugged me a little so I thought I’d post my thoughts. If you haven’t read his blog post, go check it out real quick.

Brian and I (as well as most of the rest of the web world) use the classic “*selector” and “_selector” hacks for IE6 and 7 (as shown in Brian’s post). This is fine and dandy except that Brian includes these hacks with the rest of the non-hacked CSS which I don’t agree with.

Brian argues that by including the hacks with the rest of the CSS it minimizes HTTP requests, saves time (and thus your client’s money), users’ bandwidth, etc. This is where I think Brian has gone wrong and I argue the opposite.

1. It’s just as easy to use simple conditional comments and move these hacks into a separate stylesheet. In fact, many people would argue that this way is easier and faster because you’re not mucking up the main stylesheet with a bunch of hacks and they’re all in one place instead of scattered.
2. You’ll probably actually save more bandwidth by removing the hacks from the main stylesheet and using a separate one. IE7 requires very few hacks, if any on some projects, so your primary concern will be IE6. IE6 is dying rapidly and the bulk of your visitors shouldn’t be forced to download these hacks, especially when they won’t even be used.
3. If you separate your hacks then yes, you’ll create more HTTP requests. The only people that will need the extra HTTP requests are IE6 users and possibly IE7 users (if you even need any IE7 hacks). If they don’t like it then they can upgrade their browsers. Businesses you say? Businesses have no excuse for sticking with IE6 and web developers will not keep bending over backwards for their sake. Period.
4. Last reason… validation. If you can validate, then why not? Separating your hacks from your main stylesheet will give you a much better chance for validation. Jeffrey has a great post about validation you should read. Validation isn’t a necessity but if you can do it then why not?

Anyway, these are just my thoughts on the subject. Ultimately it will come down to how you prefer to go about dealing with these issues. No one way is going to be the right way every time and it’s up to you to decide what fits your project best.