As announced at IE Death March, I recently dropped support for Internet Explorer 6. As newer versions of Firefox, Opera, and Safari (and others) continue to improve consistency and provide better support for standards-based techniques, having to carry IE 6 along for the ride — for any reason — is painful. Thanks to the techniques described in this article, I am free to completely ignore (figuratively and literally) IE 6 when developing and designing websites.

Free at last

Now that I have dropped support for IE 6, I feel liberated, free of the constraints that once enslaved my time, energy, and resources. Working on my new design, I have already saved countless hours that would have been wasted on IE 6. If you are still chained to an old copy IE 6, I highly recommend kicking it to the curb and experiencing the freedom for yourself. All it takes is a few lines of code and the decision to go there.

Turning point

For me, the decision to drop IE 6 developed gradually. Years of growing frustration, wasted time, and unsatisfactory workarounds finally reached critical mass a few weeks ago. Working on a new WordPress theme for Perishable Press, I was going with my usual strategy for browser support. Make sure the design works great in modern browsers, and also looks halfway decent (or at least recognizable) in IE 6.

As usual, after the first few hours of testing my design in Firefox, Opera, and Safari, I fired up my trusty, seven-year-old Sony Vaio laptop and opened my fledgling design in good ‘ol Internet Explorer 6.

And surprise, surprise, in IE 6 the design was a total nightmare. The CSS rendering was a joke. The layout looked like somebody had put it through a blender. The JavaScript completely failed to work. I sat for a moment, staring at the screen, asking myself if I really wanted to go another ten rounds fighting this atrocious browser. I didn’t..

New strategy

After seeing my carefully crafted design explode on IE 6, I decided then and there to kick it to the curb. As in, I’m done. No more time wasted on support for dying browsers. And you know what? Immediately after making that decision, I felt as if a tremendous burden had been lifted off my shoulders.

So to implement my new IE6 strategy, I quickly dropped a few lines of code into the <head> element of my new theme:

These two conditional comments ensure that the stylesheet is delivered to all browsers exceptIE 6 and below. IE 7, 8 and beyond will receive the stylesheet, and so will every non–IE browser, such as Firefox, Opera, Safari, and so on.

This is the easiest way to ensure that your pages remain usable when viewed in Internet Explorer 6. Simply serving your default stylesheet to IE 6 may leave your content unusable, incoherent, or worse. Personally, I would rather deliver a plain (X)HTML document rather than have visitors think I was too incompetent to design a halfway decent web page.

Going further

But why stop there? After testing this method in various browsers, I realized that some sort of explanation was required for those die-hards out there still working with IE 6. I certainly don’t want the small percentage of my IE-6 visitors to think that something is broken (other than their browser!) when visiting Perishable Press and seeing the unstyled markup. Instead of that, IE-6 users will receive the following message:

With that code placed just below the <body> element on every page, the notice will be unavoidable (yet unobtrusive) to anyone using IE 6 and below. Of course, the site will remain completely usable and accessible even without the stylish interface, but users will be gently inspired to use a better browser.

Blocker script

If you are seeking a more urgent method of encouraging your IE-6 audience to “let it go,” I highly recommend Chris Coyier’s controversial IE 6 Blocker Script, which provides an less-subtle JavaScript approach for dealing with IE 6 — and be sure to read through the comment thread of the article for some great commentary, questions, and criticism.

Other scripts

Speaking of JavaScript, if you are going to drop CSS support for Internet Explorer 6, you might as well save the bandwidth and discontinue the JavaScript love as well. Although there are many great ways to enhance a plain (X)HTML page using small snippets of JavaScript, there are many situations where plainly delivered pages don’t require an entire JavaScript library such as jQuery, Prototype, or MooTools. In fact, if the JavaScript is applying CSS styles on the fly, your plainly delivered page may appear strange or altogether broken when rendered in IE 6.

For example, if you are using a slider script that dynamically applies CSS to transform the width of a division to some large value, an unwanted horizontal scrollbar will appear when viewing the CSS-less page in IE 6. There are many other examples, but I am sure you get the idea.

Thus, to prevent a JavaScript file from being delivered to IE 6 (and below), we again turn to conditional comments to accomplish the task:

With that, all browsers exceptIE 6 and below will receive the JavaScript file. The conditional-comment technique is great not just for JavaScript and CSS, but for any type of content that needs to be hidden from or targeted to any version of everyone’s favorite browser.

Let’s blow this joint

Since dropping support for Internet Explorer 6, I am one happy camper. My design efforts now stay focused on modern, standards-compliant browsers that behave — for the most part — exactly as expected. No more surprises, headaches, hacks, or time wasted dealing with ancient history. The best part is that freedom from IE 6 requires nothing more than a few lines of code and a decision to go there.

About the AuthorJeff Starr = Creative thinker. Passionate about free and open Web.

My very bad, I didn’t know that server-side detection was unprecise. I have never used it in fact, so I’m very sad to learn that real world implementation is not usable :(

Thank you for making this clear. What I meant by perfectionnist is that I wouldn’t sleep so well at night if I knew there were “hidden” elements in my pages that target IE users only.

Still, I think bandwith is more important than server ressources. Not for the cost factor, but for the “ethics” of it. Overloading (the word is a little bit too much for our case, but in general) the tubes is a very bad practice. There was some discussion recently on my favourite performance oriented french weblog about the preloading techniques used on streaming websites like Youtube. On average, a Youtube user watch only the first 10 seconds or so, but the website preload the whole video everytime. Some other service even preload it on page loading. All this data parasites the web tubes.

Of course, this argument is a little extreme when speaking of two lines of conditionnal comments… but hey, it’s for the principle :D

I should emphasize that it is not so much the various browser-detection scripts themselves that are inaccurate or imprecise, but rather the ability of certain browsers to disguise their user-agent identification. Also, proxy use is at an all-time high, and who knows what you are going to get with all of those browsers. And finally, some browsers/devices may not send the (correct) identification at all, leaving the detection script to “guess” at the identity. I hope that makes sense. I didn’t mean to suggest that the scripts were the problem; they are simply lines of logic doing whatever they are written to do. It’s what happens on the outside that convolutes the process.

You know, I am beginning to enjoy these conversations more and more as time goes on.. ;)

@malcolm: I appreciate that fact, but it shouldn’t stop those in the know (i.e., us) from doing their best to get the word out that it’s game over for our old friend, IE6! Yes, there are still lots of people suffering with that horrible browser, but with the momentum slowly building, they too will soon get the message. The goal here is to educate and ultimately reduce that percentage to virtually zero ;)

Hi Mark, no problem — it takes awhile to wrap your head around conditional comments (at least it did for me). For the code we are using here, the goal is to hide the stylesheet from IE6 and below. To accomplish this, the first conditional comment is simply saying that we want to show the code (CSS link, in this case) to any non-IE browser. So that takes care of everything except for IE. The second conditional comment then takes care of IE by saying, “show this code only if the version is 7 or greater.” To understand this, consider the following quote from the previously linked article on conditional comments:

As a general rule, comments in code are used to hide content. When a DCC hides content, it is functioning as expected and is referred to as “positive” or “hidden.” For supported versions of Internet Explorer (5 and up), a hidden DCC will display its content only when its [if condition] proves true. If the version of IE does not meet the specified condition, the content remains hidden. Of course, all non-IE browsers will treat the hidden DCC as a regular comment and not display its content.

I hope that helps! Let me know if I may be of any further assistance with this. :)

Simply, when Microsoft use the word “downlevel,” they’re not referring to versions of Internet Explorer, but to other browsers. If it’s “downlevel-hidden,” other browsers (e.g. Firefox, Safari) can’t see the content; if it’s “downlevel-revealed,” they can.

The first time I read about conditional comments, I actually threw a quiet fit at the arrogance of it. This was back when IE 7 wasn’t even in beta, and I was a web neophyte who regularly spent 20% of my development time struggling to make Microsoft’s “latest” (i.e. five-year-old) browser display my pages correctly. Calling a measurably superior browser in active development “downlevel” when their own software was holding web development hostage seemed positively perverse!

PS: in fairness, I should explain that Microsoft were probably thinking mainly of the very old versions of IE (four and below) when they started using the terminology; to be strictly accurate, I should say that “downlevel” is equivalent to “doesn’t support IE conditional comments.” However, since IE < 4 can be effectively dismissed by nearly all web developers, whether or not a comment is downlevel-hidden or -revealed is primarily of concern to non-IE browsers. I hope you don’t feel I was misleading you, it’s just that I’m getting a little too accustomed to making vast (but helpful) simplifications for my higher-ups!

Firstly, for IE, DCC’s are supported only in IE gte 5.
Hidden DCC’s (the one without <!-->) are forever hidden in browsers other than IE.
Hidden DCC’s only display (in IE) when [if condition] is true.
Revealed DCC’s display in all browsers unless the [if condition] is false. (?)

Got it. That explains. But it will surely need refreshing when I get back to it. :D

***

So the revealed and hidden pertain to other,i.e. that is, “downlevel” browsers, huh. Nice name there Microsoft.

***

I do web design sort of as a hobby only :( so that makes me mediocrely proficient in HTML and CSS. Although I can work around designing for WordPress given that I’ve got Sandbox or Starkers or Whiteboard to start with, but not from scratch.

Nevertheless, I understand the IE plight. And I’m part of it. When I see my work in IE with the inexplicable distortions it’s done to it, I stare blankly.

I have yet to learn how to program fixes for IE, but I guess by that time the design community will have completely abandoned consideration for IE6 and below. So maybe I’d rather not, as Jeff said.