How to Deal with IE 6 after Dropping Support
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:
<!--[if !IE]><!--><link rel="stylesheet" type="text/css" media="screen" href="style.css"><!--<![endif]-->
<!--[if gte IE 7]><link rel="stylesheet" type="text/css" media="screen" href="style.css" /><![endif]-->These two conditional comments ensure that the stylesheet is delivered to all browsers except IE 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:
ATTENTION: Perishable Press no longer supports crusty old versions of Internet Explorer. Please upgrade your browser or switch to something better, like Firefox, Opera, or Safari.
To ensure that only users of older versions of IE see the message, I once again turn to conditional comments:
<!--[if lte IE 6]><h3 style="color:red;">ATTENTION: Perishable Press no longer supports crusty old versions of Internet Explorer.<br />Please upgrade your browser or switch to something better, like Firefox, Opera, or Safari.</h3><![endif]-->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:
<!--[if !IE]><!--><script src="javascript.js" type="text/javascript"></script><!--<![endif]-->
<!--[if gte IE 7]><script src="javascript.js" type="text/javascript"></script><![endif]-->With that, all browsers except IE 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.
48 responses to “How to Deal with IE 6 after Dropping Support”
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.. ;)
I’m not sure many sites could drop IE6 support altogether. I was looking at a commercial one the other day that had 75% IE users, of which 1/3 were IE6 – so that’s still 25% of their users.
@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 ;)
Hey there,
TRUST ME. I’d do ANYTHING to give up ALL support for IE. (Even to the extent of applying code that makes IE6 and below crash :D )
Quick question, could you please explain how the code works?
<!--[if !IE]><!--><link rel="stylesheet" type="text/css" media="screen" href="style.css"><!--<![endif]--><!--[if gte IE 7]><link rel="stylesheet" type="text/css" media="screen" href="style.css" /><![endif]-->I do understand the first part – the not IE part. Downlevel-revealed.
But the second part, the gte IE 7 is downlevel-hidden. How does it deliver the stylesheet to IE 7 and above then?
I might have missed something trivial. :)
Thanks
gte IE 7 = “greater than or equal to IE version 7,” I believe.
Does that help? :)
(What is it with me and typos writing simple tags?)
[ – fixed! ;) ]
Actually I do understand the meaning of gte IE 7 per se. What I don’t understand is the use of a downlevel-hidden conditional for it.
<!--[if gte IE 7]><link rel="stylesheet" type="text/css" media="screen" href="style.css" /><![endif]-->Will this not mean that the expression above will actually be hidden (instead of shown) in IE versions 7 and above?
Sorry for the inconvenience, but please clarify. I’m confused like nuts. :D
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:
I hope that helps! Let me know if I may be of any further assistance with this. :)
Ah, right! I see. Your confusion is well-placed; basically–as Jeff’s article explains–the word “downlevel” doesn’t actually mean what it sounds like it should mean!
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!
PPS: Thanks for fixing my XHTML dyslexia, Jeff!
Ah right. I’m getting a grasp of it now.
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.
Thanks guys! Appreciate it.