Taking Conditional Comments Too Far

Posted: July 23, 2007 Comments(11)

I’ve come to accept and support conditional comments as a tool to use when it’s otherwise impossible to get Internet Explorer to behave desirably. To me, they’re much more acceptable than unstable CSS hacks or extensive !important declarations. They’re much easier to maintain, and it’s the only truly reliable way to target not only Internet Explorer itself, but specify a version as well. The subject of conditional comments comes with great debate that seems to be ongoing. There are good arguments on both sides, but to me, conditional comments seem like the best solution.

When I use conditional comments

Up until this point, conditional comments have saved the day for me simply by being present in the head of my documents. For nearly every client project, I find myself using conditional comments to target both Internet Explorer 6 as well as Internet Explorer 7. In my opinion, as far as standards compliance is concerned, IE7 is merely a shuffle forward, as opposed to a step.

I’ve also accepted using conditional comments to include JavaScript written specifically to assist Internet Explorer. A specific example that comes to mind is when I’m implementing Suckerfish Dropdowns. I elect to include the JavaScript with a conditional comment simply because the script is only meant to be run when browsing the document in Internet Explorer 6. I prefer to have other browsers ignore the JavaScript for simplicity’s sake. While it may not be considered harmful to allow JavaScript such as the bit needed for Suckerfish Dropdowns in all browsers, to me it is settling to keep it separated.

Using conditional comments in the body

Until recently, it hadn’t even occurred to me that using conditional comments in the body of your document could become commonplace. There’s no documentation specifying that conditional comments can be used only in the head of your document, so why stop there? To me, using conditional comments in the body of your document is partially counter productive.

The reason I choose to employ conditional comments is their nature of providing longevity. By writing specific style sheets to target specific versions of Internet Explorer, I’m able to solve a rendering issue and leave the solution as is for the life of the document. The problem is solved with a minimal change to the DOM.

When you choose to use conditional comments in the body of your document, you’re electing to alter the DOM in a more significant way. Now, instead of working with different style sheets to solve a problem, you’re altering the problem itself. If this route is chosen, you now have a number of choices. You can alter a significant portion of the DOM in order to work with a single, existing style sheet, or you can take both sides and use conditional comments to include Internet Explorer specific style sheets as well as alter the DOM at the same time.

The idea in general, to me, seems more sloppy than resorting to the use of CSS hacks strewn throughout your document style sheet. Your source will become ugly and awkward to maintain, and the longevity of your document will be greatly reduced. Using conditional comments to include a version specific style sheet (or a bit of JavaScript) should be all the ammo you need to solve the problem of Internet Explorer.

What’s your opinion?

How do you feel about conditional comments in the first place? If you’re opposed, is it due to the fact that the code is technically proprietary? Is it due to the fact that the implementations you’ve seen are as outlined above in that conditional comments are littered across the entire DOM?

Get my newsletter

Receive periodic updates right in the mail!
  • This field is for validation purposes and should be left unchanged.

Comments

  1. Actually, conditional comments have been used for a very long time in the page content by several people, and the most notable person, whom I think you should mention in your blog post, is Stuart Nicholls (http://cssplay.co.uk/) – his approach is rather unique and fixes a fundamental problem, related to the drop-down menus, thus eliminating the need of Javascript to create multi-level drop-downs.

  2. @Alexander Gyoshev: Yes, Stu Nicholls was one of the first that came to mind when writing this article. In my opinion, while his examples are innovative for sure, they would be better suited to use JavaScript where acceptable. Using conditional comments in that way is using structural markup to affect the behavior of the document — something for which JavaScript is better suited. What do you think?

    Going beyond JavaScript-less CSS techniques, I came across conditional comments being used in the body of http://nytimes.com not too long ago. Unfortunately, the snippet has been removed, but that too was also inspiration for the article.

  3. At work the Marketing department wanted a button on the homepage, as well as final page of the order process that allowed people to make our website their homepage.

    With only IE supporting the JavaScript that provides this functionality, it didn’t really seem right to have the button displayed to all users. Conditional comments to the rescue! By far the quickest and easiest way to make sure that the “Make homepage” button is displayed to IE only users.

  4. I am a big fan of conditional comments, I see them as a clean and safe way to do the dirty work for IE and I much prefer them to hacks.

    I don’t think their use should be entirely restricted to the <head> of a document, I use them to advertise Firefox to IE users only and Calvin’s example above makes sense too.

    However I came across this article on Position Is Everything the other day and felt that it was too much. Sure, we could add extra markup to the page, but as you say, that is just changing the problem, albeit in a way that makes it easier to fix in some respects. But extra markup and another hack to target non IE browsers seemed too much.

    I guess it is down to a matter of taste in the end, but I mostly agree with you, Jon.

  5. I definitely prefer conditional comments to use of css hacks. Similar to the method Phil linked to on PIE, I’ve recently taken to using a single conditional comment block wrapping the open body tag, assigning a class=”IE [IE ver]”. This allows me to use the cascade to override style rules in a single style sheet as needed per whichever version of IE is creating mayhem in whatever fashion.

    I haven’t used conditional comments in js, as I’ve found object/member detection has proven adequate.

  6. I must admit, the comments offered here have opened my eyes to some circumstances which hadn’t crossed my mind before.

    @Calvin: In my opinion, that can be deemed acceptable use of conditional comments in your source. You’ve done a nice favor towards those not using IE.

    @Phil: Yes, including an ad for Firefox specifically aimed at IE users. You’re right, there’s definitely a gray area here. Like everything, it can be taken to an extraordinary level for sure.

    @Luke: That’s a creative use I haven’t seen in the wild before. As far as conditional comments and JavaScript are concerned, I was simply referring to wrapping the <script> snippet within a conditional comment to ensure that it was only Internet Explorer taking the time to request the file at all.

    Thanks to you guys for offering your opinions on the matter!

  7. […] Taking Conditional Comments Too Far When you choose to use conditional comments in the body of your document, you’re electing to alter the DOM in a more significant way. Now, instead of working with different style sheets to solve a problem, you’re altering the problem itself. […]

  8. I always use a conditional comment to link to an IE-specific stylesheet, even if the stylesheet only contains one stupid rule, such as a height declaration to mimic min-height. I do this because I want to make it as obvious as possible how ridiculous IE is (“see what it takes to make IE behave?”). I find this perversely satisfying.

    Up until now my CCs have only gone in the head, though. Phil’s idea of using them to advertise FF is terrific. 🙂

  9. I dislike conditional statements, they make the developer do the work of the browser. What I would like to se is standards compliance in browsers, but we can’t hope for miracles right?

    In my view, XHTML is there to markup content, CSS is there to style it and Javascript is there to make the content do pretty things. If there is a standard content should be marked up to that standard, if everyone stopped jumping hoops for IE then hopefully market forces would work and consumers would vote with their feet and start using standard compliant browsers.

    If you really want conditional statements then use a server side method, it is far more powerful and all the ugly hacks are hidden away.

  10. I use conditional comments exactly as you do. I have an “ie6hacks.css” and an “ie7hacks.css” that get included into nearly every site I design via conditional comments. I’ve never even considered putting them into the body (I just made sure a friend of mine didn’t do that last week, as I showed him the conditional comment technique). I find conditional comments far better than the * html hack, and IE7 introduced it’s own set of problems when working with CSS, even aside from its predecessor, IE6.

  11. Sorry if you find this off topic. However I think this can be a good tip if we can solve it.

    I use conditional events too. However I have run into a problem with it.

    I have two seperate css files for IE7 and IE6 in my online portfolio located at http://cssfreeancer.awardspace.com .

    IE6 mysteriously using IE7’s css file in addition to it’s specific css file. This causes IE6 not to render the page as intended in some cases such as the shadow of the bg pic in the header and div in “about portfolio” section.

    When I disable the other.css file which is for browsers other than IE6, then IE6 is just fine. Problem occures when other.css file is enabled.

    Have you guys run into the same problem before? could somebody help to solve this please?

    thanks in advance.

Leave a Reply

Your email address will not be published.