Some people compare web development to other industries/ technologies, but forget that those industries are a little more contained than web development (rendering at least). If you are trained to fly an airplane it is for a specific type of airplane, not airplanes in general. Yet web developers are expected to render sites in 7 (or more) browsers, despite the total lack of adherance to standards.

Conditional comments themselves feel like a hack to me — you’re not using comments as specified. At the end of the day, who are you making the site for? Do you have a heirarchy? Mine is my employer, the public, myself, then the development community.

P.S. fewer http requests = smaller carbon footprint (lame, I know)

TLDR: Until there’s no longer such need, bad browsers beget bad CSS. Simple as that.

Unfortunately, some institutions are still using IE6 (my wife’s workplace with 2000+ employees) and have to have pages that will display properly in them. My solution has been to do designs that “work” (degrade gracefully) in IE6 but shine in everything else.

I’m not convinced totally of the maintainability argument you pose. One could include their main CSS references to CSS files unique IE versions containing only hacks and delete the unique files as time goes on without having to update all the pages that have the conditionals. The problem with this approach could be argued that one has to remember to delete the appropriate browser version file when the time comes. One wouldn’t need to remember to do anything with the conditionals.

Your maintainability argument does become more justified when the author isn’t going to be the one that maintains the css. Trying to understand somebody else’s approach in the use of a hack to solve some issue can be easily confused with something that wasn’t intended as a hack at all. Conditionals remove this ambiguity as well as the need to remember to remove browser specific sheets outlined in the previous paragraph.

I’m just glad I don’t have worry about IE3 :)

1. I agree with Brian on the first argument. I find my CSS easier to maintain when I solve my problems where they occur, using these hacks, rather than splitting them off into separate files.

You say separating out the rules for outdated browsers with conditional comments leaves your standards-compliant stylesheets clean and easy to manage, but I’m not managing the CSS for modern browsers; I manage it for all supported browsers, including IE6 and IE7. The only time you might be saving here is the time it takes you to remove support for IE6/7, and a search-and-replace to remove the _ and/or * rules is hardly any more work than deleting the relevant conditional comments and files.

In the mean time you’d have to carefully comment your main CSS file, referencing all IE fixes, to prevent you from accidentally breaking your site in IE when you make any changes to the main CSS. (You do that, don’t you?)

you don’t have to wade through multiple rules looking for the ones you need

I sort my properties alphabetically, and I don’t think I’ve ever needed more than a few hacked properties (per ruleset) for IE; hardly any wading.

IE6 & IE7 styles are safely out of sight

Why would you want them to be out of sight when you need them for your site to work on the browsers you support? If you don’t support IE6/7, fine, but then you wouldn’t be using any hacks or separate stylesheets in the first place.

For example, the IE6 stylesheet on this site seems to be outdated and become unnecessary since neither of the IDs mentioned in it actually occur on your site anymore, as far as I can see.

2. Secondly, first you say [d]isregarding the ‘rights’ and ‘wrongs’, and the validation argument, and then your second argument is “future-proofing”. I don’t see how this can be about anything other than validation.

You’re only partly right with this argument.

The CSS 2.1 spec says this about valid stylesheets:

A valid CSS 2.1 style sheet must be written according to the grammar of CSS 2.1. Furthermore, it must contain only at-rules, property names, and property values defined in this specification. An illegal (invalid) at-rule, property name, or property value is one that is not valid.

If you look at the grammar of CSS 2.1 you’ll find that it is perfectly valid for a property to start with an underscore. So the only thing that makes those properties invalid is the fact that they’re not defined. But that is no different from the vendor-specific extension such as –webkit– or –moz-, and technically all CSS3 properties that haven’t reached the recommendation state yet.

In fact, the current draft of the CSS3 Syntax module defines the underscore as a vendor-specific extension as well. So whatever it may be, it is certainly future-proof.

The same can not be said for the *, though that same Syntax draft also says:

If a style sheet cannot be parsed according to the grammar above, the user agent must behave the same as it would if the style sheet had the smallest sequence of characters removed from its end that would allow it to be parsed according to the grammar.

So it should be safe to use, though clearly illegal.

But there is an alternative for the *: you can use “\ ” instead.

E.g. body { background: green; \ background: orange; _background: red; }, which will turn the body green in all standards-compliant browsers, orange in IE7 and red in IE6 and before.

The “escaped space” construction is valid according to the CSS grammar, so it is future-proof (so long as they don’t start adding properties starting with an escaped space), and as far as I’ve tested works the same as the * hack: I tested it in IE6, IE8 (in IE8, IE7 and Quirks mode), Firefox 3.5, Firefox 2.0, Safari 4.0, Opera 9.6 and Opera 10 (beta 3) and only triggers in IE7 and IE6 (and IE’s quirks mode).

3. I think Brian already addressed well enough.

Also, in your reply to Brian, that IEBlog post you link to does not actually go out and say developers should stop using hacks altogether. It asks developers to look at the specific hacks they mention in that post, because those targeted IE6 by relying on bugs in its CSS parser which were fixed in IE7.

Finally, none of this means I never use conditional comments or always think using the underscore/star/escaped space hacks is the best solution. I just use whichever I find most appropriate.

I think the real question is industry certification, why shouldn’t the web development world have certification tests. the certification standards may be hard to develop, but I feel the end result would help both the client (a small measure of confidence added) and the development community by creating an industry wide barrier to entry, which should help cut down on the fly by night types that are rampant in this industry.

Sorry a little off topic but that’s my 2cents.

Nope. One conditional comment for IE6, one for IE7.

Or one conditional comment for both ;)

I would never use any of the underscore or / hacks in the middle of the definitions — those are ugly and invalid, and seem dangerous for future-proofing.

Personally, I think the best overall approach is to use IE conditional comments to write the <html> tag — using the comments to add a class of ‘ie6’, ‘ie7’ etc. to the html tag. Then that class can be used to target rules for a specific browser without resorting to hacks or separate style sheets. The drawback here is that it only works when the developer has enough control over the markup to do so — which isn’t always the case, unfortunately.

“If you only need 5/10 lines to fix IE issues, should you really add another style sheet? One more request for your server for just 5 lines?” — If your site is so small that only 5/10 lines are needed to fix IE6, I’m sure your server can take the extra hits. Yahoo and Google use invalid stylesheets, don’t close some tags, put the whole markup in one line, etc, because they serve to millions of visitors per day and the costs involved are phenomenal; you don’t have that excuse, I’m sure.

“If you use conditional comments, sometimes you need to make specific browser styles for IE6 or IE7, and to do that, you must use hacks.”

Nope. One conditional comment for IE6, one for IE7.