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”
@Jeff L: yes, actually you are correct about the flash of styled content in the current theme’s IE6 presentation, but thankfully this theme is not employing the methods described in the article. This theme was actually designed about a year ago, when I was still supporting IE6. I had implemented a stylesheet switcher (sun icon, bottom-right corner of screen) for the contrastedly challenged among us, but just could not for the life of me get it to work in IE6 (hence the flash of styled content). My workaround in that case was to provide links to both of the alternate stylesheets, which persist perfectly once the user manually selects one of them. Until they do, however, the stylesheet-switching JavaScript prevents any default stylesheets from loading properly.
All of that to say this: The methods described in the article provide a clean, consistent, and efficient way of dealing with IE6 after dropping support. These methods are not implemented in this current theme, and will not produce any undesirable flashes of styled content in any browser.
I hope that makes sense — sorry for any confusion, Jeff!
@Mathieu Beausoleil: i wish it were always that easy, but in my experience, IE6 requires too much fiddling around, hacks, etc. And not just with CSS either; IE6 is known to choke on simple JavaScript as well. I get what you are saying, and in some cases, throwing down support for misaligned floats or transparent PNGs is not a big deal; however, as newer browsers continue to provide greater support for newer CSS, (X)HTML, and JavaScript, at some point it becomes foolish to try to twist, tweak, and hack old versions of IE to behave without crashing. This isn’t a new concept by any means: we were able to let go of Netscape, and we can let go of IE too..
@Trav: amen, brother! :)
I don’t think the conditionnal comments technic is the best approch here. You are making everyone – including people with up-to-date browsers – download the IE6 adressed HTML.
It’s not deadly to make a Firefox user download 4 lines that he won’t use, but when it comes to SEO, I wouldn’t recommend to have each and every of your pages contain content that is not displayed.
Though, your idea of “no stylesheet at all” is nice. I would keep this part, but would place the warning message using a server-side detection (i.e. using PHP or Apache).
—
On a more personnal side now: I’ve moved to my own student flat this year, and I’ve been without internet there for quite a while now. It should be fixed this week, as I’ve ordered a box from my favorite provider, but for now, I can only read PP when I’m at my father’s.
Jeff my friend, I miss to read you regularly :(
Hi Louis, I agree that the extra few lines of conditional comments adds some extra page weight, but is there a better solution? Server-side detection isn’t foolproof, and also requires additional server resources for every page. As for the SEO pros and cons, I have not read anywhere that conditional comments negatively (or in any way) affect the page in question. Perhaps you know otherwise..?
—
Your own student flat, eh? Sounds nice, except for the lack of Internet access. Hopefully you will be able to connect soon — your presence is sorely missed! ;)
Well, that’s basically the dilemma here: work a little more on the server side and serve the clients tailored pages, or be lazy and drop them large-size clothes, and let them deal with it.
As for SEO, Google and the big others obviously are able to detect hidden text – hidden by CSS, conditionnal comment, or whatever – so it’s more for the sake of it for me.
I mean, we all love to have
<title>tags that precisely and uniquely describe the nature of each page. It also serves SEO, but it’s nice to know we have chosen them wisely.The same thing apply to the content: it feels nice to know that a page doesn’t contain content that has no reason at all to be delivered.
—
The techical work to do things well is pretty simple also. If you serve static content – and on a site full of ressources like PP, you definitely should – you would just descriminate the browsers at the Apache level, and serve a IE6 tailored page, or a “modern browsers” tailored page.
If you calculate your page with each request, you can simply add a PHP condition around the stylesheet and the warning.
Aaaah, I can’t wait to have internet up and running at my new home!
I don’t do web design for a job, but I am in every spare second writing code, expanding my skills, and just basically trying to learn and create as much as I can.
I’m rarely, if ever, surprised at how my recent pages look in Opera or Safari – in fact I often don’t bother to test. Sometimes I look in IE6 as a joke. When it looks good, I’m surprised. IE7 does a bit better, even though it’s getting pretty old now. IE8 does even better as long as there’s no javascript (mine’s normally unobtrusive anyway)
I suck, I’m an amateur. But I am getting more professional faster and faster since I stopped writing code for IE6.
Remember I’m not paid for it, I’m doing it for kicks.
But.. I’m so upset with IE since stopped writing code for it last year, that as a rule of thumb, I won’t even give code to someone if I think they’re going to test it, look at it, edit it, or roll it up and smoke it with Internet Explorer.
I know ONE person who uses IE6. I’m telling him every day to get off it. If he doesn’t, I seriously don’t think I can be his friend any more.
I laughed when I wrote this. It all sounds quite funny, I’m sure – but I’m dead serious, even while laughing about it just now. See, told you web design was fun.
@Louis: I agree that conditional comments could be used inappropriately, such as would be the case if you were deliberately trying to pull some black-hat SEO stuntz, but I disagree that two sentences delivered within a conditional comment to old versions of IE would somehow negatively affect the overall integrity or rank quality of a page.
In fact, even though the conditional comments are only seen explicitly by users of old IE, including the information in the source code of all pages is an excellent way to communicate to other designers and developers (and anyone else who might be checking your source code) your intentions concerning various versions of IE. I see conditional comments (as used in this context) as a positive or at worst neutral part of any given page. It conveys useful information to those who can use it, and hides it everyone else. Further, it’s the browser that processes the code — the user doesn’t have to “deal” with anything.
Beyond these points, I would also point out that every PHP evaluation required by the server consumes additional resources. In terms of performance — which is more important than any perceived negative effects caused by (over)generalized pages — requiring an extra PHP evaluation for every page request is not as efficient as including a few lines of conditional content in the markup.
@Louis and Jeff:
The pros and cons of conditional comments.
As Louis said it could seem illogical to force people with updated browser downloading 4 more lines of code.
Yes, it COULD seem.
But think about coding in general.
How we do our best? How we learn?
How we improve our skills?
Yes we do it all by good teachers, by communications, by meeting people and disussing about our works.
But even with COPYNG (call it “inspiration”).
When I see a SOURCE CODE of a page I can find wich solution the author used to solve some issue.
I like it.
If the solution is applied by server side application I have to open the page with several browser to see the code-differences.
Server-side solutions are fastest, nicer and logically better but client-side solution are more “visible”.
Why worry about some few bytes more when someone doesn’t care build up heavy-weight-flashsites?
@H5N1: because some of us are perfectionists :)
@Jeff: I tend to thing that bandwidth is more valuable than server ressources these days. Server-side calculations – and browser recognition is quite nothing – are a lot more cheap in terms of performances than having to send the user additionnal bytes to ensure that the display is correct.
If I extend your philosophy, a website viewed on a mobile device may have the same source code as the website viewed on a classic browser, but with some additionnal code (CSS/JS) to ensure that it displays correctly on the smaller screen.
I still think that the server is the right actor for browser discrimination; sending tailored content to each browser.
@Louis: I disagree that “bandwidth is more valuable than than server resources.” In my experience, everything boils down to server memory, modules, applications, databases, processing, and so on. Conversely, most web hosts are giving away bandwidth by the truckload! But this is a small point compared to my central criticism against browser sniffing:
Detecting various versions of IE is not as reliable as detecting conditional comments from within various versions of IE.
Until I can find a 100% foolproof script that enables consistent, reliable, and efficient browser detection, I will continue to deliver IE-specific stylesheets, JavaScript, and brief messages via conditional comments and simply let IE work it out. Unlike with browser detection, I have never encountered any inconsistencies with this method.
I don’t understand you, Louis; if you truly are a “perfectionist” as you suggest, why do you sacrifice accuracy and precision for the sake of a “cleaner” method?