Why “Conditional Comments” Are Bad, Repeat: Bad

Post from February 1, 2007 (↻ December 12, 2016), filed under Web Development.

This and many other posts are also available as a pretty, well-behaved e-book: 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 an inadvisable thing to use. In fact, they contradict the goal to separate structure from presentation, and they will outrun you one day.

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

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

Rarely (meaning never) is that the only style sheet included in a document; usually, CC fans include some “regular” style sheets and at least one, if not three or more style sheets solely to address Internet Explorer needs. (Or perceived needs, respectively.)

What Is Wrong with Conditional Comments?

Two important things.

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” (old, but sufficient reference).

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

Also, the standardization process was weak, at best. That is just natural for proprietary “solutions,” but the Web has rarely profited from proprietary stuff. Conditional Comments are no exception. While you think they help you, they will just eat you anytime, since…
Conditional Comments guarantee your HTML to be changed, while they mix the to-be-separated structure and presentation. Think about it.

Surely depending on the way 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—even if you’re the most visionary master of web development and there’s just no need to update the structure of your documents. Remember that you strive for absolute separation of structure and formatting.

Clearly, at least the next redesign will force you to update your style sheets—even better, your style sheet, singular—, but now you just entered the lottery and will not only need to maintain at least one additional style sheet, no, you’re most likely forced to update all the clever IE comment queries when there’s any highly critical security update containing support for “a few more selectors.”

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

Tips

Set taboos for your work, and these should include “no Conditional Comments.” Try to communicate that. Explain why they don’t help. I know companies where effects are desired (and have already been promised to clients) that you cannot address otherwise, but solve this problem by getting to the root, ask your team members if these effects are really useful, and rather stick to graceful degradation. It will make you happy one day.

❧ Apologies for this somewhat cluttered guerrilla post, but the point had to be made, and it should have been made now.

Update (February 2, 2007)

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

Also, there’s only one case where Conditional Comments might not become a problem, apart from being non-compliant and generally impairing: When you’re a one-man-show that is responsible for HTML and CSS maintenance. In other cases, you won’t only force yourself but—worse—team members to update HTML files and/or templates, style sheets, and probably to even work on file level (removing ie5.css, renaming ie.css, creating ie8b.css). Don’t think too idealistically—just a quick “search and replace” won’t do when CC changes become inevitable.

So don’t get lured. Conditional Comments appear safe, they apparently validate, but that’s an illusion, and they’re bad.

About the Author

Jens Oliver Meiert, photo of April 13, 2018.

Jens Oliver Meiert is an author and developer (O’Reilly, W3C, ex-Google). He plays with philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences. (Beware: More often than he wants it he’s wrong.)

There’s more Jens in the archives and at Goodreads. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

Comments (Closed)

On February 1, 2007, 22:06 CET, David said:

Right on! I hate that these even exist for the same reasons you just stated. We just did a complete re-design at my place of work, where we’ve used conditional comments in the past, and I found it very annoying to have to make changes in more than one place. Maintenance nightmares should be avoided at all cost, so why would anyone consider this segregation in the first place?
On February 2, 2007, 1:04 CET, Jens Nedal said:

1. Here i find myself pretty much in the same boat. The fact that Conditional Comments (CCs from now on) are not standard compliant is a total minus to the whole procedure. This counts for ’some’ of the CSS hacks out there as well.

Concerning that only some of the CSS hacks are not compliant puts them in favor for sure.
The fact that when IE browser versions change, some will not be supported is the disadvantage.

Although CCs are not compliant, once they are set there is only need to look for changes in newer browsers and add new CSS if needed for that specific version. Everything else remains the same and one has not to worry about updating those very few lines of code saved in the CC specific files, ever. The main stylesheet that is in use should not ever need to be touched, otherwise something is wrong with your structure.

—

2. CSS rendering problems covered by CCs are box model, PNG24 rendering and min-height.

The maintenance is minimal, since it only covers a few select problems, just like CSS hacks do. Structure always remains the same and must not be dictated by IE or any other browser.
Should you need to change structure because of using CCs something is wrong with your structure, meaning you go back to the drawing board!
Otherwise i would have thrown the whole CC idea over board long ago.

Personally i would not like to advocate either CCs or CSS hacks, since both have their drawbacks. All i can say is, i know CSS hacks, i grew up with CCs.

—

I don’t think this about being a fan of either of the 2, but just about which tool suited the screw best first, before the other tool fell into my hand.
Your other article made me think about the whole thing since bringing up the compliance problem.

Concerning the 1st comment in this article: The side factors of how to maintain CSS files and what structure you use is important, though as long as the logic is simple (meaning easy to understand for you and others), what structure you use will not matter. Both CCs and CSS hacks have simple logic.

Knowing how to employ CSS hacks and CCs shows us, that both are basically used for the same type of thing, with different appliance.

What both ways teach though is one thing. DON’T use ANY of them, unless you REALLY have to! Before considering using them, think twice. If you see you are gathering more than a few lines of code in CCs or CSS hacks, something is wrong with your structure and you should reconsider.

My conclusion? None yet. Compliance is important, but what will i do the next time i need to replace a hack and no hack is there to fill in? Maybe i need to learn more about CSS hacks? *goes reading some more*
On February 2, 2007, 8:06 CET, Matthias said:

Sorry, but I don’t agree with most of you points when you are advising “to use the naughtiest CSS hacks and filters and workarounds that you find” instead of Conditional Comments (CC).

1. CCs are syntactically valid, they are not standards compliant.
Sure, but how is this an argument for using hacks? Are hacks standards compliant? Even if you say they are (this is question of interpretation what “standard compliance” exactly means), they are definitely und unquestionable not valid. What is more important, fulfiling (questionable) the by-letter meaning of a specification document, or prevent causing parsing errors?

2. CCs guarantee your HTML to be changed.
No. Why should they? If I give an element a 1% height in a conditional stylesheet to force IE into the “hasLayout = yes” mode, how does this change my HTML?

I took this out of your point 2:
3. You’re most likely forced to update your clever IE comment queries when there’s any highly critical security update containing support for “a few more selectors”.

Is this an arggument against CCs? No, of course not: exactly the same will happen to your hacks, and even more likely: What if the bug that is causing your hack to work is fixed, but the bug the hack should prevent is not, or vice versa? THIS is a much bigger “lottery”. In contrast to hacks, CCs can and should be aimed at certain browser versions, so your CC-workaround for IE6 wil never bother IE7. Your hack will.

There is another argument for preferring CCs over hacks: Your CCs will never cause a problem in any Browser that they are not aimed at - can you state the same with a clear conciense about your “naughty hacks”? Definitely not.
On February 2, 2007, 11:10 CET, Jens Oliver Meiert said:

Thanks for all your comments so far. They even encouraged me to update the post.

Matthias, please see the update. Regarding 1. and compliance, compliance is defined by the respective specification; and regarding 2., Conditional Comments refer to HTML, as you cannot use them without changing HTML.
On February 2, 2007, 12:05 CET, Jens Nedal said:

This is kind of turning into a discussion about work structure ethics, which might be part of the whole approach too, but seriously this cannot be considered as an argument against CCs or for CSS hacks at all.

You might(!) as well argue, that finding CSS hacks in one file will take more time, since you will have to search for the right place in the code. With CCs you just choose the right file, change a few short lines and thats it and don’t have to worry about the hundred lines of code in the main file.

Both arguments are unfounded since they only reflect the work ethics of an individual or a team, and bascially you do the same thing. You search/replace. If someone’s editing skills are not up to doing a fast search/replace in 1 or more files, than one should better reconsider beiing an application developer for anything.

A team has to establish their working ground and all team members have to adhere to that structure, be that using CCs, CSS hacks or whatever other structure.

Should the case arise, that a developer has not touched unto a project yet, it is his responsibility to look and see where all information is gathered and what structure is used.

I agree with your argument to keep things simple, but both approaches are simple.

In a CC scenario there will be a couple more files in a directory which are clearly named. If that is not good for the team, or they can’t agree on that structure, then please go forth and use a different one that might include the use of CSS hacks.

Your argument to favor hacks before CCs is to itchy for me. I say, favor none and if you have no choice agree on a procedure with your team and thats it.

Just emphasizing that CCs are “bad” is like trying to emphasize an argument that apart from the compliance part(!) lacks a ground to support it totally.

Both are on the same boat that can loose its balance anytime when browser vendors upgrade to more compliant CSS rendering. Both are using techniques that can be non-compliant.

About changing HTML: Yes the header is changed obviously, to contain the CCs. Otherwise the structure remains the same.

Your comment about “illusion” also goes in the direction of using “bad”. Emphasizing arguments with no ground attached.

Compliance is something that certainly makes me think though. Again i would advocate neither CCs nor CSS hacks!
On February 2, 2007, 12:33 CET, Jens Oliver Meiert said:

Jens, well, I guess I don’t need to repeat what I wrote before.

The entire topic is about standards compliance (which makes CC a taboo), maintainability (where in most cases CC will be counterproductive), and finally the “vision of CSS.”

Concerning hacks and maintainability: Evil me, I just added “yet valid” when it comes hacks, that’s what I left aside before. It’s also important to note that it’s in every developer’s responsibility to comment workarounds anyway, to make sure they can easily be removed, modified, or whatever later. (For example, denote an IE specific declaration with /* IE */ for example; the more specific the UA is named, the better.)

It will become quite difficult to argue about the CC problem when we now drift towards web development “philosophy,” expertise, and “secondary virtues” like work organization, structure, and style. Of course.
On February 2, 2007, 16:38 CET, David said:

Jens Nedal, I strongly disagree with your assumption that all CC work around consist of just “change a few short lines and thats it”. At my job our CC style sheets are several hundred lines of CSS. That is beside the point as well. You should always, always, always avoid creating maintenance.
On February 2, 2007, 18:08 CET, Jens Nedal said:

Okay, sofar so good. I agree on compliance.

David: If your CCs have more than 100 lines of code, then the whole setup of your structure is wrong. If i were to have more than 10 lines of code in the CC files that we use i would immediately revert to CSS hacks and forget the whole ordeal. Any use of either methods that require you to change more than a few small lines are useless! With the experience you have with CCs i would react no differently.

I think the discussion is on a stalement here and all have made there points. Interesting to read what others think about this and how others work with CSS. Between i have been thinking about getting a copy of your book Jens.

kind regards, Jens
On February 5, 2007, 16:26 CET, Nathan Rutman said:

Of course, this largely ignores the most prolific uses for Conditional Comments: targeting old versions of IE that will not easily conform to CSS basics (box models, etc.). With IE7, I find it fairly easy to get my pages to work well between IE7 and other browsers. The problem is with IE5.5-6. There, Conditional Comments don’t hold promise for future problems since the parsing rules for IE5.5 or IE6 won’t change. Feed fixed measurements to those browsers, and you’re set!
On February 5, 2007, 16:51 CET, Richard Rutter said:

Disregarding workflow for a moment, it would seem to me that I would disagree that CSS hacks are a conditional comments a more reliable way to get around bugs in IE/Win than CSS hacks. CSS hacks inherently rely on a bug to fix a bug, whereas CC rely on a feature to fix a bug.

In terms of reliable use among teams, it is of course advisable to avoid CC or CSS hacks wherever possible, however as we all know life isn’t that simple. So where IE-specific workarounds are needed, our workflow is to put those rule in a separate style sheet called via CC and - most importantly - to document the normal style sheet where rules are being overwritten (as is normally the case).
On February 5, 2007, 17:43 CET, patrick h. lauke said:

as i always said, conditional comments are browser-specific, proprietary markup masquerading as a harmless comment. the fact that they validate is irrelevant…they’re just as wrong as adding proprietary *anything* (attributes, elements, etc) to code.

i also don’t quite follow the rationale some CC fans peddle: “if a new version comes out, you’ll have to find another hack…not so with CCs”. actually, if a new version comes out, i’d rather wait a few days until a hack surfaces and then change my CSS accordingly, rather than having to futz about with every single piece of HTML. and again, as i said at the time of the “* html is evil” debate on chris wilson’s blog: IE developers should stop trying to fix the bugs that enable the hacks, but the actual bugs that force developers to use hacks in the first place…
On February 5, 2007, 17:50 CET, Montoya said:

I have my own reason for avoiding conditional comments which I recently posted on my blog: Why I avoid using conditional comments. It’s nice to find someone who thinks alike 😊
On February 5, 2007, 17:53 CET, Barney said:

I’m glad this view is becoming more widespread. It’s only recently that people are dropping the long-standing myth that anything other than CCs is intrinsically invalid.

To those who still maintain the latter point of view: CCs only pass automated validation because you are hiding functional markup from the validator in the guise of comments. It is a hypocritical duplicity to boycott invalid CSS while using trickery in HTML, where standardisation is absolutely vital (arguably it is vital to have invalid CSS in order maintain a standard experience accross browsers).
On February 5, 2007, 23:35 CET, Anson said:

Totally disagree.

CC’s are much more maintainable in that you centralize your design workarounds in a single file (or potentially a few files if you have highly specific CCs). Relying on bugs in a browser’s rendering engine (i.e. CSS hacks) is a bad, bad practice. As is scattering hacks throughout all your CSS files. Very hard to maintain this.

As others have commented, you have know way of knowing when the bug you’re exploiting for your CSS hack will be patched and how other browsers will deal with it in the future.

Conditional comments are by far the lesser of two evils. Particularly since you can directly target versions of IE and throw these away when IE eventually makes it to standards compliance.
On February 6, 2007, 0:35 CET, Jens Oliver Meiert said:

Anson; no. CC collide with everything we strive for, and they are a sleeper maintenance problem. Meanwhile, all major points should be covered by this thread.
On February 6, 2007, 0:41 CET, jonnny_noog said:

I also have to disagree with the main thrust of your post. I am a web developer who generally tries very hard to make sure that the sites I work on do validate and are standards compliant, and yes, it does irk me somewhat to know that CC’s go against the HTML specification… But not enough to stop using them.

To me, CSS hacks are more messy, that’s just my subjective opinion. I’m not going to rehash all the points for and against that we all already know, but I will point out that even the smallest sites that I build these days make use of includes of some kind, specifically to make it easy on my self when I do have to go in and change a line in the head tag or whatever.

I also have found (as another poster noted, I think) that IE7 tends to be pretty good in my experience so far, I am mainly interested in targeting IE5/5.5/6 with CC’s, and as much as I am no big fan of M$, I do think that if IE7 is any indication, they will move towards a more standards compliant browser with each new release.

I understand the argument for full separation of structure and presentation and how CC’s violate this principle… But try explaining this forward thinking principle to a computer illiterate client at 6:45pm on a Friday when their website doesn’t look like they think it should in IE and see how much they care.
On February 6, 2007, 5:07 CET, Ben Buchanan said:

CCs annoy me because they destroy one of the key advantages of CSS: being able to maintain a whole site by changing the stylesheets. The CC way means you have to go back to the bad old days and edit everything you have, just for one browser.

If they were going to make up a non-standard conditional hack (CCs being a hack dressed up as legitimate code, nothing more), they should at least have done it in the CSS.
On February 6, 2007, 11:20 CET, Gerry Quach said:

We only recently started using conditional comments in our sites. Up until then we were using a large variety of CSS hacks.

I’m now convinced that CSS hacks are not the way to go, and CCs are a necessary evil. CCs are to be avoided where possible, but if not, they provide a consistent and reliable way to fix IE/Win rendering bugs.

Most importantly, I can be confident that CCs will continue to work correctly with all future versions of IE, whereas with CSS hacks this cannot be guaranteed. This is perhaps the most critical advantage of CCs.

Sadly, even IE7 has shown itself to require the occasional CC, in order to fix problems it has with the Son of Suckerfish CSS dropdown menus.

In the future, once IE5/Win and its ilk have dropped into obscurity forever, I can simply take out the CCs from my markup and discard the IE-specific stylesheets, and I’m done.
On February 6, 2007, 16:56 CET, Anthony Cartmell said:

While “Conditional Comments” are syntactically valid, they are not standards compliant

Yes they are standards compliant. What isn’t standards compliant is the way IE uses them. As you point out yourself, all other browsers treat them as perfectly valid and standards-compliant HTML.

I can’t believe you prefer to have a single style sheet littered with hacks (that rely on bugs to work!) over a set of style sheets, one for standards-compliant browsers, plus a set of minimal ones, included by conditional comments, adding in overrides for specific IE versions.

With conditional comments, I may have to add another line to my HTML page-top file when a new IE is released, although future CSS fixes will probably mean that I won’t.

With CSS hacks, you have to test every hacked style to see both whether the bug still exists in the new IE and also whether the new IE still needs the style fix. And you’ll need to do that every time a new IE is released (and that includes updates!).

CCs only pass automated validation because you are hiding functional markup from the validator in the guise of comments. It is a hypocritical duplicity to boycott invalid CSS while using trickery in HTML, where standardisation is absolutely vital

The stuff in conditional comments is not functional markup, it’s a comment. The fact that IE reads the contents of that comment, allowing you to fix problems with IE, makes no difference to the validity of the HTML.

“Information that appears between comments has no special meaning”, and comments “will be ignored by the parser”

Exactly. The standards do not say “information that appears between comments must have no special meaning, and may not be used by the parser”, which is I think what the original article tries to suggest.
On February 6, 2007, 20:19 CET, pauldwaite said:

While “Conditional Comments”… are not standards compliant

I’m going to venture a distinction here: Internet Explorer’s recognition of conditional comments as having special meaning is not standards compliant.

As such, I don’t see the difference (in purely standards-compliance terms) between conditional comments and CSS hacks. With CSS hacks, you’re taking a non-standards-compliant CSS behaviour, and using it to tackle another non-standards-compliant CSS behaviour.

“Conditional Comments” guarantee your HTML to be changed

Very true. However, I think you’ve overstated a couple of the negative consequences.

you’re most likely forced to update your clever IE comment queries when there’s any highly critical security update containing support for “a few more selectors”.

Internet Explorer has had one update to its rendering engine in 5 years. While we’re all expecting further updates to arrive more quickly, the conduct of the IE team thus far suggests that we’ll have a fair bit of warning when they do. Aside from that, the IE team seem to be making great strides towards standards compliance in CSS. As such, it may be that IE 7.5 or 8 has few enough bugs not to require any more special measures. By the time they come along, IE 5 may also be rare enough to drop IE 5-specific stylesheets, thus meaning the number of stylesheets to maintain stays the same.

And, as you say, the changes necessary to include another stylesheet via conditional comments may be nothing more than changing one line in one template file (this would be the situation, for example, for my employer’s ASP.NET web site).

As far as “renaming ie.css” goes, conditional comments are designed to target specfic versions of IE. If you’ve got a stylesheet called “ie.css”, you’re not using conditional comments very well.

I’m very glad you’ve sparked a debate over this. I can certainly understand that some developers may prefer to keep all their CSS inside one stylesheet (or as few stylesheets as possible). I personally prefer to write my stylesheets as if all browsers had a decent level of standards support, and keep the IE-specific rules in their own stylesheets, so that I know exactly how much extra work it is supporting them.

I think this is somewhere where reasonable developers can disagree.
On February 6, 2007, 21:35 CET, George said:

Agreed you should try and avoid CCs and hacks if you can but it is a fact of life you will need to use one technique at some point.

For me CCs are far better. Look at the pain that IE7 caused to many who had been hacking away in their main stylesheet.

I agree that neither approach is perfect but CCs are the lesser of two evils for me.
On February 6, 2007, 21:59 CET, Darren Wood said:

Maybe I’m doing it wrong, but my ‘iehacks.css’ stylesheet (that’s called from a CC) only has - at most - 10 lines. This is WAY easier than maintaining nastly CSS hacks sprinkled throughout the default.css file…

Each to their own, I say. We (me the other developers who work on my code) find CC’s the only way forward in terms of getting sites to render semi-correctly in IE. And easy to maintain.
On February 7, 2007, 0:20 CET, Paul W said:

Conditional Comments have been intentionally created to violate the HTML specification

I believe they were created to solve a problem Microsoft had (due to bugs in it’s browser).

Information that appears between comments has no special meaning

This is written in the context of explaining SGML and gives the example of character references not being interpreted. After that it says:

Note that comments are markup.

It doesn’t say browsers MUST NOT do anything with that markup. BTW, another specification that exploits this ambiguity is Trackback, which I understand to be quite popular, however ugly it might be.

(Your other quote is from the HTML 3 spec. It is out of date. Again, it is general guidance on HTML’s relationship with SGML and there is no MUST IGNORE type language.)

Saying CCs are not standards compliant is, I think, reading a lot more into these quotes than they explicitly state.

CCs are good because they are future proof. No other browser is going to implement this quirky syntax. They will only ever affect the IE versions you choose to target.

With CSS hacks, no-one can say how they will be interpreted by future browsers.

As to changing your HTML, most (modern?) sites are template driven. I’ve been writing mark-up 6 or 7 years and I’ve never come across a site with more than one header template.

A quick anecdote to illustrate: I’m currently working on a redesign for an international recruitment site. The IE target was version 6 and above. Once the CSS was done it’s checked in and the website goes through rigorous QA testing on all target browsers. This costs time and money.

Picture my boss’s embarassment when he presents this in the boardroom and it turns out the laptop they have is running IE5. The board is not happy - I have to get this working in IE5. Now if I did that with CSS hacks the whole QA process would have to be repeated for all target browsers, to make sure none of the hacks upset anything.

As it was (and as I prefer to), I used conditional comments. The developer had to include one line in the header template to include a CSS file that contained about 10 lines and the QA testing had to be repeated for one browser.

(Aside: I think some people are under the impression using CCs means you have to maintain a complete duplicate of your default stylesheet. This is not the case; the styles you include via CCs only need to contain the ‘corrections’ for IE browsers.)

The developer was happy because it was clear what this one line did, he knew it wouldn’t affect other browsers, no additional documentation had to be written (as CCs are pretty much self documenting, unlike the voodoo of CSS hacks which I didn’t have a spare 2 hours to explain to him) and it wouldn’t break the validity of the site.

The boss was happy because the board was happy he didn’t have to spend more time and money repeating a process on an already late and over budget project.

To labour the point, CCs do not invalidate your HTML, are easy to maintain, self-documenting, future proof and may even save some time and money 😊 Can you say that about CSS hacks?

Sorry for the long comment, but I really felt a practical example was needed to illustrate exactly why CCs are safer than relying on parser bugs.
On February 7, 2007, 19:23 CET, Mani Sheriar said:

I have to respectfully disagree with the author, although I value his thoughts and appreciate the debate they have sparked.

I only relatively recently began using conditional comments to feed separate style sheets to both ie6 and ie7. Before that I did exactly what this author recommends … relying on valid “hacks” throughout my one stylesheet (I was a BIG fan of using the !important declaration to feed certain values to the “good” browsers and then override them for ie). This method simply became a total nightmare to maintain. I cannot emphasize this enough. It was completely unmanageable. Even so, I clung to my view that it was better than CCs to the very end!

When I finally “gave up” and began using CCs I was amazed at how much easier everything was. I won’t go into details, as so many here have already done so (I think comment 26 described it best), but truly, it simplified my coding life immensely.

I have a hard time even beginning to grasp how doing things the way I used to do them could present less of a maintenance headache. However, each to her own.

Thanks for the article.
On February 7, 2007, 19:41 CET, Jens Oliver Meiert said:

Mani, I can relate when you’re talking about maintainability problems due to more or less heavy use of !important declarations—you’re then adding an entirely new dimension which can even make “regular” style sheets challenging to maintain.

I… enjoy the discussion. Only a few contributors seem to accept CC as a taboo, only a few seem to have (“valid,” once again) CSS filters under control (provocative, right). And most of you’re quite optimistic about the future with CC.
On February 8, 2007, 14:27 CET, pauldwaite said:

> “I guess we need to talk more about web development goals and philosophy here, garnished with more examples. Sounds good, right?”

Always good 😊
On February 9, 2007, 14:29 CET, Jon Christopher said:

I’m really glad that this article sparked a conversation filled with intelligent remarks and opinions.

Respectfully, I too will disagree with the author as well as the other developers who support CSS hacks over CC. First and foremost, if your CC style sheets are 100 lines long, you have some issues that root with your original style sheet, not IE.

I don’t want to regurgitate what others have said, but standards compliant browsers treat Conditional Comments as comments and truly ignore them—intended purpose. While including a Conditional Comment does change your HTML, I don’t feel it’s doing much different than including your external style sheet.

The most common reaction I read about Conditional Comments is that they’re bad because they’re proprietary. While that’s a valid point, they’re proprietary in a way that doesn’t interfere with more advanced products. They’re proprietary in that they’re a crutch for an inferior product, and the developer of that product knows it. All of the troubles you have with Conditional Comments (maintenance, etc.) are exactly the same problems you’ll have with hacks in that you’re still doing the same ‘work’, just in a different way. With Conditional Comments, however, you’re able to know exactly what to edit. Theoretically, providing conditional comments should decrease the time needed for maintenance in that you’re able to target specific versions of IE and there are no overlapping hacks to deal with.

Again, the major issue that struck me was that some CC style sheets are ~100 lines long. That is missing the point of Conditional Comments. These style sheets should be quite small in nature (throwing out a number, mine are usually about 4-10) and easy to maintain. We’ll always have to test in each browser, and there will be times where there are single browser issues that need attention.

I think the true issue for me is the scope of hacks versus the scope of Conditional Comments. Hacks do what they do because every browser processes them, and the ‘good’ browsers render as expected, and you’re taking advantage of the many shortcomings of an inferior product in other cases. The latter is, in my opinion, an extremely unstable method to work in, and in essence harms the longevity of your styles and site as a whole.

As far as standards compliance, I’m not sure why people feel Conditional Comments are not compliant. IE isn’t standards compliant, and it’s the only browser which does a thing with Conditional Comments. I fail to see how this one instance of IE not being standards compliant is having an affect on the general perception of leaving CSS hacks in the past. Just because hacks are valid doesn’t give anybody the green light to use them, the same goes for (X)HTML. A document can be constructed with completely valid markup, but if the markup doesn’t make any sense, the document has lost much of it’s worth. Personally I feel the same idea is pushed upon style sheets.

I look forward to keeping up with this conversation, thanks to the author and all of the intelligent people who took the time to post their thoughts.
On February 11, 2007, 13:33 CET, Jordan Clark said:

Although I do agree with you in principle, I think that if you have to use hacks, CCs are useful for isolating the workarounds.
Users of ‘good’ browsers get a faster download, and when older versions of IE (hopefully!) die out you can delete the hacks in one fowl swoop.
I currently use a CC on my personal web site, but I am hoping to phase it out soon.
On February 13, 2007, 0:46 CET, Colin Lieberman said:

I have to agree with Matthias and John Cristopher—Jens, I think you are mistaken.

Conditional comments are almost a god-send: the manufacturer of the most problematic browser gave us a way to specifically target versions of that browser, with no fear of bungging anything up for other browsers. This is great.

CSS hacks are exactly that, hacks. We don’t know how reliable they’ll be in future versions or in browsers we never think about.

Conditional Comments let us cut right to the problem - if this is IE with a version less than 7, do such-and-such.

As to your other criticism - in what way are they not standards compliant? If the standard says “ignore all the jazz in comments”, and all the browsers except IE do this, then it’s a win-win situation.

The correct criticism should be “IE does not parse comments correctly.” That’s IE’s problem, not ours. If they fix it in IE8, the guess what, it will ignore conditional comments, which is exactly what we’d want to happen anyway.

As for making life difficult for a development team, I can assure you just the opposite is the case. I work in 3-man development team. Good source control (which should be part of any serious development effort) makes updating code among the team a no-brainer. As for conditional comments specifically, I’d rather explain to a new team member “all the IE7 stuff is in ie7_main.css, and IE7 pulls that in via a conditional comment” than “that * html hack is supposed to get IE 6 and below”.

Maybe I don’t fully understand your arguments, because I just don’t see what damage conditional comments do.
On February 21, 2007, 12:34 CET, Destry Wion said:

Jens,

First, I can appreciate this kind of discussion, glad to finally see it (though I think it’s about 8 years too late). I am in the camp where I see hacks or CCs alike being something to avoid whenever possible.

However, I personally would go with a CC over a classic hack anytime to isolate a few lines of CSS to make something work in an old version of IE; doing so with the happiness of knowing that in the near future I drop both the CC and the associated file in 30 seconds of work. Not too tough.

You seem to have an agenda against CCs beyond just discussing their utility or not, like they are a cancer in the markup that can only be bad. Contrarily, they might be considered more a sterilized nano-robot in that same body, having a specific task to do. When the task is finished, the robot is removed and the body is right as rain. Nothing wrong with that.

There are no rules, only “recommendations” from the W3C. If the W3C said don’t use CCs, that might hold more weight in the grand scheme of things…but they don’t. Truth is, CCs, however you want to paint them, are a viable way to treat a viable problem without interfering with one’s aims at improving compliance everywhere else.

Peter Paul Koch suggests CCs are one of the only three safe (sure to work unfailingly over time) hacks to count on. I tend to agree there.

Also, CCs are handy for flexy-widths, which in turn are a great way to deal with horizontal scrolling issues without fixed widths of 750px or long lines of text in 17″+ monitors. This is mostly what I use them for, as do other folks like Roger Johansson, a true standards evangelist.

In any case, they shouldn’t be necessary for very long, by indication of IE7’s fast adoption rate and the already anticipated next release of IE. In that light the entire issue is rather pointless because 5, 5.5, and maybe even 6 will be toast when the next IE comes out (I know, I know, but that’s another issue people). Folks can then drop their CCs for those browsers, and with any luck, won’t be needed anymore. 😊

It’s a time thing, man. If we take sensible steps to deal with problems in potentially low-maintenance ways without really bucking the long-term goal (full compliance) then there’s no need to grab pitchforks and torches.

My two cents, respectfully.
On March 8, 2007, 9:44 CET, Craig said:

It’s great to find people who have the same opinion as me! Conditional comments are just another way of browser sniffing. I’d hoped the industry had abandoned that 5/6 years ago.

It’s far better to have one stylesheet that works in all browsers. End of story!
On March 15, 2007, 21:56 CET, Dennis said:

I respectfully disagree with your article. I’d tend to say “using IE is bad, repeat: bad”. The IE browser itself is the reason we developers must use Conditional Comments in the first place since it doesn’t adhere to standards as Microsoft makes up its own rules.
On April 3, 2007, 22:00 CEST, Dan said:

I rather like the CCs. I was going nuts trying to get a site done for my church, and was not surprised when it rendered poorly in IE6 but looked fab in FF2. The CSS and HTML (strict dtd) validated. This SHOULD be the point when the developer can say the project is complete…but alas IE was mocking me and putting my floating divs where it thought they looked better in the overall design.

A quick CC and some minimal css on my ie6 stylesheet put it back in its proper place. I agree with jonnny_noog and his 6:45 pm comment…too true.
On April 4, 2007, 3:09 CEST, Dan said:

I actually disagree with this quite a bit. I think they’re a much more elegant way to take care of things. It’s only a little extra markup in the head (which probably shouldn’t be considered such a harsh violation of the structure/presentation rule). Most of the hacks are pretty ugly and cumbersome, and they always leave me a little nervous that they’ll be misinterpreted by a particular browser. And finally, I mean, 80% of the hacks are for IE in the first place! Furthermore, as MS releases newer versions the hacks are being ignored and layouts are breaking. It’s a nightmare to keep up with it. I say use conditional comments. Actually, if you’re familiar with Facebook… Their site is rock solid, XHTML strict, amaaazing work… They use conditionals which I thought was pretty cool…..
On April 16, 2007, 9:07 CEST, Nils said:

Now you got me courious. What are all those people with those long iehack.css putting in there? Mine usually aren’t longer than about 10 lines.

Are you adapting size information? IE does render em a little differently. I really would like to now, as most people commenting here do seem to know what thea are doing.

Anyway, I think we all can aggree on IE being the real problem here 😊
On April 16, 2007, 20:06 CEST, Elijah said:

CC’s are a way of exploiting a feature rather than a flaw. CSS hacks are exploiting flaws. They will break as technology evolves. No question about it.

CC’s are a feature, and as such, are more “valid” than CSS hacks in the fantasy-land of abstraction so many web developers live in.

The arguments about CC’s not being “standards compliant” sound like lawyer’s arguments to me. What does it really matter? No meaning? What about a comment I write to myself? It has meaning. Why have comments at all if they are meaningless?

And one last question: what in the world… in all the universe (aside from interpretations of spec verbiage) is the harm in having a comment that means something? You’d think the W3c was a religious organization the way people behave about this stuff.
On September 2, 2007, 15:14 CEST, René said:

Hm, i agree in parts with you Jens.
If possible i’ll avoid the usage of CCs but sometimes, working on projects for some agencies with their own creative artists, it becomes a problem, that other browsers didn’t have a same solution like Microsoft with CCs.

What if a style definition works well in FF but only in Windows. If you visit the site with a Mac it becomes a terrible desaster because of one damn pixel. Wouldn’t be great if we could say – if FF mac, do this, else do anything what i’ve defined before? Same thing… i’ve found a damn bug between FF 1.0.4 and the latest Version. The old one didn’t renders some things like the new one and we don’t have any possibilities to handle that.

And no, there is no problem in my styles or my markup.

Another prob… safari… because of the different behaviour, e.g. os-dependent rendering of buttons, textareas and input fields i’ve to find a solution only to fix this only browser. The hacks i’ve used where valid as the w3c validator said. But they kill Firefox’ debugger.

Wouldn’t it be great if we could present all users the same layout?

For me CCs are only a solution to keep older browsers as long users using them. I hate those badges… “sorry, your are using Browser X but we only support Browser Y”.

If the w3c would recommend conditional comments no one would ask about the usage…

Thanks,
René
On October 19, 2007, 1:29 CEST, Patrick Garies said:

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 (old, but sufficient reference).

Conditional comments are not a compliance issue for the author; the compliance issue lies with the user agent (i.e., Internet Explorer). Consider them a convenient exploit (i.e.., “hack”).

As long as a document works properly and is compliant in a standards‐compliant browser when the CCs are removed, I don’t see what makes them any more wrong than use of CSS exploits since CSS exploits also exploit lack of user agent compliance.

CCs can also mean a better experience for the user since, when you externalize all of that proprietary stuff, standards‐compliant browsers don’t have to download and read it. You can also do this in reverse with so‐called “down‐level revealed” CCs to speed things up for Internet Explorer users. This means that pages load faster, particularly for dial‐up users, the server has less strain placed upon it, and scripts can be executed with less overhead.

Issue 2:

Conditional comments only hurt maintainability if you’re using [if IE] with no references to version numbers. Unless Microsoft applies a non‐security patch that affects coding language support without changing the version number, I don’t think that this will be much of an issue.

It’s true that you would probably have to add more CCs in the future, but at that point, you can decide to take the trouble (at which point you’ve decided that the trouble is worth your time) or you can decide to move to CSS exploits if adding more CCs is too much trouble.
On November 20, 2007, 23:59 CET, Richard Jones said:

I have to say that I find CC very useful and a good method to aid learning how different versions of IE work (or fail).

I like to keep as perfect a stylesheet as possible. Well ordered and well commented. I would hate to have to go back to two years ago and to start littering my stylesheets with hacks for the abomination that is IE6 (and lower).

So using one CC I make one IE stylesheet that is pointed at all IEs which contain any hacks required. Usually only a couple for IE7 and the rest are generally just ‘height: 1%;’ hasLayout fixes for the others. I then know that everything in the main stylesheet is perfect for proper browsers.

When a new IE version comes out and I’m testing and therefore learning about this version, I have already separated/hidden all the ugly hacks from this version. I can then see what this version fails to render properly and fix, either by adding new hacks to the IE stylesheet, or (hopefully not) adding another CC just for that version.

This seems to work perfectly for me and maintenance is minimal. If I do have to fix the CC in the HTML, I only have to do it once as I always use server-side includes.

But if there was a way to not use CCs whilst still achieving the above, I’d use that in a second. The CC in the head is just another reminder of one of the banes of my life.
On December 5, 2007, 1:07 CET, minimal design said:

I think you misunderstand the use of conditional comments. You don’t need to “maintain” them separately from your main css files. You should use them to load CSS files AFTER the main CSS. That way, you just address the few IE specific caveats like box model, PNG transparency, etc… It’s pretty much the equivalent of keeping all your hacks grouped and isolated from your clean Standards compliant css code. In my personal experience, this makes it a lot easier to read CSS files and therefor a lot faster to update/modify.

And adding an extra call to an external CSS file doesn’t mean you’re changing the structure of your HTML document. When talking about separation of presentation and structure/content, people refer to what’s inside the body, not in the header.

Your claim that the IE specific CSS file will need to be updated when IE will “support for a few more selectors” makes no sense for 2 reasons: #1 everyone knows how often IE CSS support is updated… #2 you’d have to update your hacks just the same way if that were to happen. Only, with conditional comments, you’d find the lines to edit much faster than looking for hacks intermingled in your general CSS… AND you can target specific IE versions much more easily than with hacks.

I don’t know what you mean by the “standardization process was weak” since those conditional comments are by definition not standard… there’s useful only for IE and work very reliably in IE…

Lastly, setting “taboos” makes no business sense when you work for real clients with real money. And *promising* that following your advice will make me “happy one day” is both patronizing and devoid of any practical justification.
On December 9, 2007, 18:40 CET, Callum said:

I really am confused at how you can consider CCs a maintenance problem. Here is the big problem with hacks: when you write a hack for one browser, you might adversely affect another.

I always have three stylesheets: one “main.css” for all browsers, then an extra one each for IE6 and IE7—just a few lines to address specific problems in these browsers. Like this:
<link rel="stylesheet" type="text/css" href="main.css" />  

It’s great; if I spot something not working properly in IE6, I just make a change to the IE6 stylesheet. I know that the changes I make will only affect IE6—they definitely won’t harm IE7, Firefox, or any other browser. If I tried to do it with a hack, I would have to test in every browser to ensure that the hack hasn’t caused problems. (I used to do this, and I sometimes ended up creating a hack for another browser to address the problem that the first hack caused… crazy.)

Even worse, hacks might even cause problems for browsers that haven’t even been released yet! What happens if a new version of a browser comes out, and it chokes on a CSS hack? Using hacks means that, to be absolutely safe, I have to revisit every website I’ve ever made whenever a new browser version is released.

Also, how can you say that CCs are not standards compliant? They are. They are comments, and comments are fine. The fact that IE reads these comments and acts on them means that IE is not standards compliant. It doesn’t mean my code is not standards compliant.

And what about this:

“Surely depending on the way 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”

Why?

You also said “stick to graceful degradation”. How do CCs impact upon graceful degradation?

I’m sorry, but I think this post is very wrong, and I think you should consider revising your bizarre view that “Conditional Comments appear safe, they apparently validate, but that’s an illusion, and they’re bad.” No, it’s not an illusion: they are safe (they are guaranteed to only affect one browser, unlike hacks); and they do validate (no “apparently” about it).

Hacks are bad. Hacks are not standards compliant. Hacks are difficult to keep track of.

Conditional comments are completely harmless and very convenient. Please consider admitting you were wrong.
On December 16, 2007, 9:16 CET, Wes said:

This discussion smacks of the tables vs. CSS debates of yore. Don’t bat for the wrong team this go around Jens.

Internet Explorer is in need of correctional CSS. You seem to have realized this. You’re exasperation over this simple solution is therefore baffling.

Hacks are so named for a reason. As you yourself put it:

CSS “hacks” usually depend on parsing bugs, syntax errors, or just missing support for certain spec ingredients…

Has it occurred to you that browser manufacturers have, and will continue to, correct bugs in their software?

The underscore or slash hacks, for instance, are liable to be patched. I’d like to hear you explain the merits of hacks vs. conditional comments to an angry customer on that occassion. Or perhaps your customers are the sort that don’t care about their websites.

So far as them being unmaintainable, your argument is poor at best. When IE8 comes out it will (hopefully) have better CSS support than ever. Since my sites have no IE8 specific sheet, it will be served the same valid, well-tested CSS the other blokes get. In all likelihood everything will continue working without a single change. If they’ve corrected any of the infamous parser bugs you rely on, however, you’re stuck updating every stylesheet you put your dirty hands on.

On the off-chance I need to introduce a new IE stylesheet, a global find/replace for </head> should do the job in a wink.

Some of us have work to do. Some of us don’t have time to change hundreds of stylesheets after inconsequential browser patches. Some of us have customers who don’t tolerate sloppy hacks, invalid CSS, or broken websites.

To be frank: your own inability to create an understandable and maintainable stylesheet hierarchy with conditional comments is a poor argument against them. Used correctly they are a tool to keep your standards-compliant CSS (and developers) neatly seperated from ugly hacks.
On December 16, 2007, 9:28 CET, Wes said:

Also, of great importance:

The behaviour of conditional comments is understandable and intuitive to another developer. If IE 5, do this. Not so for hacks. What’s this !@#$%^&*()_-+=/?.,|[]{;:_background: red; rule do? Why, it makes the background red in IE only! No really—it does. Somehow this is easier to document and maintain in a collaborative setting?
On December 16, 2007, 12:31 CET, Jens Oliver Meiert said:

your own inability to create an understandable and maintainable stylesheet hierarchy with conditional comments is a poor argument against them. Used correctly they are a tool to keep your standards-compliant CSS (and developers) neatly seperated from ugly hacks.

That I recommend hacks over CC does not mean that I recommend hacks.
On December 17, 2007, 20:30 CET, Joe R said:

I think your logic is lacking. I see no problem with developing a main stylesheet that works in all browsers, and any minor defects that you can’t correct for IE within that main stylesheet you can just add to a small secondary stylesheet put inside a CC. That way you don’t have 2 20k css files, you have 1 20k and 1 >1k css file. And your css files WILL validate!
On December 28, 2007, 1:05 CET, Dieter said:

The necessity of “Conditional Comments” is the result of bugs from the IE.

My point of view: CC are better than using bugs to solve bugs from the IE.

The best is: Both are from Microsoft and you can use CC to blame Microsoft like I do. You can use CC not only to hide CSS. You can also use them to hide HTML for other browsers than IE. For example: Only if you visit my website dieter-welzel.de with an IE you will see my commendation to change the browser.

I think everybody should also use CC in this way. 😉
On March 5, 2008, 1:27 CET, Brian said:

Conditional comments are guaranteed to continue working in the future the same way they work now. They are safe for this reason.

Hacks, on the other hand, have no such guarantee (or even a mild expectation); their future behaviour is completely undefined. That hack you use today WILL break (and unpredictably so) in some future browser. They are UNSAFE for this reason.

This simple and unavoidable fact completely trumps idealistic notions about absolute standards compliance.

Jens wrote: “depending on the way you use CC, it will be necessary to adjust the HTML of each and every document”.

First, why would this be NECESSARY? CCs target existing browsers (ie, that will not change), so CCs can be safely left in place indefinitely with no ill effects regardless of what browsers come out in the future. The same cannot be said for hacks.

Second, even if you DID need to “adjust the HTML of each and every document”, so what? The same problem exists when you have to update the copyright year, or add a menu item, or update ANY common site element. This is just part of a web developer’s job, and why sites are generally built using templates or includes, so you just make your change in a single spot.

In my designs, I strive for a single stylesheet, using techniques that work the same in all browsers, and am successful on about 80-90% of my sites. The rest of the time I am able to use CCs to cleanly target specific IE bugs (generally IE6) with only a handful of additional rules. This is very easy to maintain.

People who have “hundreds of lines” in conditional sheets are obviously going to have maintenance issues; my advice to such people would be to focus on your global stylesheet more, getting it as close as possible in all browsers before adding any needed conditional tweaks.
On March 5, 2008, 11:05 CET, Jens Oliver Meiert said:

This discussion has been quite interesting, passionate for sure, but there are no new arguments for a while now, and so I close it. You may want to check out the equally… provoking “five questions for CC fans” follow-up until I write something more, non-controversial.

Have a look at the most popular posts, possibly including:

Looking for a way to comment? Comments have been disabled, unfortunately.