Why “Conditional Comments” Are Bad, Repeat: Bad

Published on Feb 1, 2007 (updated Feb 5, 2024), filed under development, maintainability (feed). (Share this on Mastodon or Bluesky?)

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

This post is not as clear as it could be (and the tone is odd). Please refer to more recent posts on Conditional Comments, most notably To Be Clear (on Conditional Comments and Resets).

“Conditional Comments” (CC) are inadvisable to use. They contradict the goal of separating structure from presentation, and because of that they will hurt you one day.

But first things first. For those lucky developers who don’t know what Conditional Comments are, please see Microsoft’s “specification” or refer to the following code snippet. It’s an HTML extract showing a comment that contains a link to a specific IE style sheet.

<!--[if IE 5]>
  <link rel="stylesheet" href="ie5.css" type="text/css">
<![endif]-->

Rarely is that the only style sheet included in a document; usually, CC users include their “regular” style sheets and then one if not more style sheets to address Internet Explorer needs.

What’s Wrong With Conditional Comments?

Two things.

1. While Conditional Comments are syntactically valid, they are not standards-compliant: “Information that appears between comments has no special meaning,” and comments “will be ignored by the parser.”

   (Interestingly, that is exactly where all other implementations except Microsoft’s Internet Explorer are correct: They just ignore comments.)

   The standardization process was weak, at best. That is natural for proprietary solutions, and Conditional Comments are no exception. While you think they help you, they will eat you at some point, since…

2. Conditional Comments guarantee your HTML to be changed, because they mix to-be-separated structure and presentation.

   No matter how you use CC, it will be necessary to adjust the HTML of each and every document or template once you focus on other Internet Explorer versions. This happens even if you’re the most visionary master of web development and there’s otherwise no need to update the structure of your documents. Remember that you strive for consistent separation of structure and formatting.

   Normally, your next redesign would require you to update your style sheets—even better, your style sheet, singular—, but now you entered the lottery and will not only need to maintain additional style sheets, no, you’re likely also forced to update all these IE comment queries.

   It’s easier and also more “pragmatic”—if that’s what’s desired—to use the naughtiest (yet valid) CSS hacks and filters and workarounds. At least they live in style sheets, at least they only force you to do work when it comes to one file type.

Tips

Set guardrails and taboos for your work, and these should include “no Conditional Comments.” Communicate that. Explain why they don’t help. I know companies where work results are desired (and have already been promised to clients) that you cannot otherwise accomplish, but solve this problem at the root, ask your team members if these results are useful, and instead rely on graceful degradation.

❧ Apologies for this somewhat cluttered guerrilla post, but I wanted to make this point.

Update (February 2, 2007)

For clarification: When I talk about using “the naughtiest CSS hacks,” I recommend them over Conditional Comments (my IE character escape filter post includes a few notes concerning the use of hacks). Use them scarcely, use them wisely, but don’t forget that they’re a different story—CSS “hacks” usually depend on parsing bugs, syntax errors, or missing support for certain spec ingredients, while Conditional Comments have been intentionally created to violate the HTML specification.

Generally, there’s only one case where Conditional Comments might not become a problem: When you’re a one-man-show who’s responsible for HTML and CSS maintenance. In other cases, you won’t only force yourself but—worse—team members to update HTML templates and style sheets, and even work on a file level (removing ie5.css, renaming ie.css, creating ie8b.css). A quick “search and replace” won’t do when CC changes become necessary.

Don’t get lured. Conditional Comments appear safe, they look valid, but that’s an illusion, and they’re bad.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for small and large enterprises, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)