Welcome to the new design! Please report any bugs or issues, thanks :)
Web Dev + WordPress + Security

Quick Reminder About Downlevel-Revealed Conditional Comments..

As more and more people discover the flexibility, specificity, and all-around usefulness of Microsoft’s proprietary downlevel conditional comments, it behooves us to reiterate the importance of utilizing proper syntax. Specifically, for downlevel-revealed, or negative, conditional comments, the commented content will remain visible unless the associated if condition proves false.

Update! This entire article amounts to nothing more than an in-depth learning experience. After writing the article, I realized (painfully) that either format for the second iteration of the downlevel-revealed comment for XHTML is perfectly fine and displays no ill effects or unwanted characters in any browser. Thus, this article is essentially useless, but I am posting it anyway because I just hate deleting several hours of hard work..

For example, if we were using XHTML and wanted to hide a specific CSS file from Internet Explorer 6, we could employ the following conditional comment:

<!--[if !IE 6]>

<link rel="stylesheet" href="http://domain.tld/css/advanced.css" type="text/css" media="screen" />

<![endif]--> 

<!--[if !IE]><!-->

<link rel="stylesheet" href="http://domain.tld/css/advanced.css" type="text/css" media="screen" />

<!--<![endif]-->

Within this negative conditional comment, the target CSS file will be delivered to all browsers except IE 6. Within the XHTML code, there are two slightly different instances of the same conditional comment1. Specifically, in the second iteration of the comment, notice the presence of “<!-->” immediately following the if statement. As written, this small portion of code works perfectly and as expected in all browsers. Unfortunately, there is some misinformation out there on the Web that presents the following erroneous version of such a downlevel conditional comment:

<!--[if condition]>

[...content...]

<![endif]--> 

<!--[if !IE]>-->

[...content...]

<!--<![endif]-->

See the difference? Instead of the syntactically correct “<!-->”, this improperly written comment uses “-->” instead. So what’s the big deal? This erroneous code results in unwanted characters appearing in all versions of Internet Explorer for which the conditional comment is revealed (in our example, all IE other than version 6). Because of the incorrect way in which such comments are occasionally written, the following characters are displayed directly before the comment contents in all revealed versions of IE:

-->

To see this unwanted display for yourself, check out the test page demonstrating both correct and incorrect versions of the conditional comment. Note: the if condition for the test page has been changed to hide from IE 5 in order to accommodate a greater number of users. Upon examination, the test page will display the contents without error in non-IE browsers, but will display the incorrect comment code in all versions of Internet Explorer other than 5.

Update

As discussed in the note above, this entire article was a learning experience. It turns out that either format for the second iteration of the downlevel-revealed comment for XHTML is perfectly fine and displays no ill effects or unwanted characters in any browser. Here is the code used for the test page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>
		<title>Perishable Labs - Testing Page: Downlevel-Revealed Conditional Comments</title>
	</head>
	<body>
		<h1>Proper Syntax for downlevel-revealed conditional comments</h1>
		<h2>View this page in any version of Internet Explorer <em>except</em> version 5.</h2>
		<h3>See <a href="" title="">this article</a> for more information.</h3>
		<hr />
		<div>
			<h4>This is the CORRECT way to write downlevel-revealed conditional comments for XHTML:</h4>
			<!--[if !IE 5]>
				<p>The correct way leaves no unsightly dash markings in IE when the comment is revealed.</p>
			<![endif]-->
			<!--[if !IE]><!-->
				<p>The correct way leaves no unsightly dash markings in IE when the comment is revealed.</p>
			<!--<![endif]-->

			<h4>This is the INCORRECT way to write downlevel-revealed conditional comments for XHTML:</h4>
			<!--[if !IE 5]>
				<p>The incorrect way leaves comment dashes in IE when the comment is revealed.</p>
			<![endif]-->
			<!--[if !IE]>-->
				<p>The incorrect way leaves comment dashes in IE when the comment is revealed.</p>
			<!--<![endif]-->
		</div>
		<hr />

	</body>
</html>

Footnotes

Jeff Starr
About the Author
Jeff Starr = Designer. Developer. Producer. Writer. Editor. Etc.
The Tao of WordPress: Become your own WordPress guru.

3 responses to “Quick Reminder About Downlevel-Revealed Conditional Comments..”

  1. Nicolas Hoizey 2009/03/18 11:35 pm

    Great article, thanks!

    I saw elsewhere this syntax (hope I can put code in the comments):

    <!--[if gte IE 7]> <!-->
    <link rel="stylesheet" href="styles.css" type="text/css" media="screen" />
    <!--> <![endif]-->

    What do you think of the end of this syntax?

  2. Jeff Starr
    Jeff Starr 2009/03/22 8:22 am

    Hi Nicolas,

    This is a great idea, but unfortunately it won’t validate as either HTML or XHTML. Unless we are excluding all IE ( !IE ), additional markup is required for proper validation. For HTML, your conditional comment would need to be written as follows:

    <!--[if gte IE 7]><![IGNORE[--><!--[IGNORE[]]-->
    <link rel="stylesheet" href="styles.css" type="text/css" media="screen" />
    <!--<![endif]-->

    And for XHTML, you would write this:

    <!--[if gte IE 7]>
    <link rel="stylesheet" href="styles.css" type="text/css" media="screen" />
    <![endif]-->
    <!--[if !IE]><!-->
    <link rel="stylesheet" href="styles.css" type="text/css" media="screen" />
    <!--<![endif]-->

    For more information, check out my article on Downlevel Conditional Comments.

  3. Nicolas Hoizey 2009/04/14 8:54 am

    OK, thanks!

Comments are closed for this post. Something to add? Let me know.
Welcome
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
.htaccess made easy: Improve site performance and security.
Thoughts
Checking in to anyone listening. Stay safe. Pay attention. Don't get lazy.
What's up with Plesk UI lately? Especially on Chrome it looks just awful, all kinds of broken. Come on Plesk devs get it together.
Things get stressful, I try to pray. Not always easy, but always helps to relax and regain focus.
Nice new speed checker at fastorslow.com.
Easy way to exclude certain tests from WP Site Health: Site Health Tool Manager
Excellent (and free) tool for getting tons of site SSL infos: whynopadlock.com
Everyone just stay home and hide forever. Brilliant idea.