Archive: December 8th, 2008

The IE6 Equation

This article first appeared in 24 Ways, the online advent calendar for geeks.

It is the destiny of one browser to serve as the nemesis of web developers everywhere. At the birth of the Web Standards movement, that role was played by Netscape Navigator 4; an outdated browser that refused to die. Its tenacious existence hampered the adoption of modern standards. Today that role is played by Internet Explorer 6.

There’s a sensation that I’m sure you’re familiar with. It’s a horrible mixture of dread and nervousness. It’s the feeling you get when—after working on a design for a while in a standards-compliant browser like Firefox, Safari or Opera—you decide that you can no longer put off the inevitable moment when you must check the site in IE6. Fingers are crossed, prayers are muttered, but alas, to no avail. The nemesis browser invariably screws something up.

What do you do next? If the differences in IE6 are minor, you could just leave it be. After all, websites don’t need to look exactly the same in all browsers. But if there are major layout issues and a significant portion of your audience is still using IE6, you’ll probably need to roll up your sleeves and start fixing the problems.

A common approach is to quarantine IE6-specific CSS in a separate stylesheet. This stylesheet can then be referenced from the HTML document using conditional comments like this:

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

That stylesheet will only be served up to Internet Explorer where the version number is less than 7.

You can put anything inside a conditional comment. You could put a script element in there. So as well as serving up browser-specific CSS, it’s possible to serve up browser-specific JavaScript.

A few years back, before Microsoft released Internet Explorer 7, JavaScript genius Dean Edwards wrote a script called IE7. This amazing piece of code uses JavaScript to make Internet Explorer 5 and 6 behave like a standards-compliant browser. Dean used JavaScript to bootstrap IE’s CSS support.

Because the script is specifically targeted at Internet Explorer, there’s no point in serving it up to other browsers. Conditional comments to the rescue:

<!--[if lt IE 7]>
<script src="" type="text/javascript"></script>

Standards-compliant browsers won’t fetch the script. Users of IE6, on the hand, will pay a kind of bad browser tax by having to download the JavaScript file.

So when should you develop an IE6-specific stylesheet and when should you just use Dean’s JavaScript code? This is the question that myself and my co-worker Natalie Downe set out to answer one morning at Clearleft. We realised that in order to answer that question you need to first answer two other questions, how much time does it take to develop for IE6? and how much of your audience is using IE6?

Let’s say that t represents the total development time. Let t6 represent the portion of that time you spend developing for IE6. If your total audience is a, then a6 is the portion of your audience using IE6. With some algebraic help from our mathematically minded co-worker Cennydd Bowles, Natalie and I came up with the following equation to calculate the percentage likelihood that you should be using Dean’s IE7 script:

p = 50 [ log ( at6 / ta6 ) + 1 ]

Try plugging in your own numbers. If you spend a lot of time developing for IE6 and only a small portion of your audience is using that browser, you’ll get a very high number out of the equation; you should probably use the IE7 script. But if you only spend a little time developing for IE6 and a significant portion of you audience are still using that browser, you’ll get a very small value for p; you might as well write an IE6-specific stylesheet.

Of course this equation is somewhat disingenuous. While it’s entirely possible to research the percentage of your audience still using IE6, it’s not so easy to figure out how much of your development time will be spent developing for that one browser. You can’t really know until you’ve already done the development, by which time the equation is irrelevant.

Instead of using the equation, you could try imposing a limit on how long you will spend developing for IE6. Get your site working in standards-compliant browsers first, then give yourself a time limit to get it working in IE6. If you can’t solve all the issues in that time limit, switch over to using Dean’s script. You could even make the time limit directly proportional to the percentage of your audience using IE6. If 20% of your audience is still using IE6 and you’ve just spent five days getting the site working in standards-compliant browsers, give yourself one day to get it working in IE6. But if 50% of your audience is still using IE6, be prepared to spend 2.5 days wrestling with your nemesis.

All of these different methods for dealing with IE6 demonstrate that there’s no one single answer that works for everyone. They also highlight a problem with the current debate around dealing with IE6. There’s no shortage of blog posts, articles and even entire websites discussing when to drop support for IE6. But very few of them take the time to define what they mean by “support.” This isn’t a binary issue. There is no Boolean answer. Instead, there’s a sliding scale of support:

  • Block IE6 users from your site.
  • Develop with web standards and don’t spend any development time testing in IE6.
  • Use the Dean Edwards IE7 script to bootstrap CSS support in IE6.
  • Write an IE6 stylesheet to address layout issues.
  • Make your site look exactly the same in IE6 as in any other browser.

Each end of that scale is extreme. I don’t think that anybody should be actively blocking any browser but neither do I think that users of an outdated browser should get exactly the same experience as users of a more modern browser. The real meanings of “supporting” or “not supporting” IE6 lie somewhere in-between those extremes.

Just as I think that semantics are important in markup, they are equally important in our discussion of web development. So let’s try to come up with some better terms than using the catch-all verb “support.” If you say in your client contract that you “support” IE6, define exactly what that means. If you find yourself in a discussion about “dropping support” for IE6, take the time to explain what you think that entails.

The web developers at Yahoo! are on the right track with their concept of graded browser support. I’m interested in hearing more ideas of how to frame this discussion. If we can all agree to use clear and precise language, we stand a better chance of defeating our nemesis.

Hubble Space Telescope Advent Calendar 2008 - The Big Picture -

An advent calendar from the Hubble telescope. Check back every day for a new image.

Feedback loopy

24 Ways is back again this year. Today’s article is a little something I penned called The IE6 Equation. Share and enjoy!

The design of 24 Ways has been refreshed for this festive season and it has prompted quite a varied reaction. That’s always a good sign. You might love it or you might hate it but you’re probably not ambivalent about it. Veerle has written more on this subject, provocatively asking Do you innovate or opt for the safe route in web design?

The implementation prompted as much feedback as the design itself. Clearly, 24 Ways is a site with an immovable deadline. It’s an advent calendar so it must go live on December 1st. This year, that meant that some cross-browser issues weren’t sorted out on the first day. A few days after the site launched, everything was hunky-dory but in the interim, there was a clamour of epic fail! from indignant visitors to the site. I’m finding that Andy’s thoughts on this term of derision has become the canonical document to point people to for a healthy dose of perspective.

Merlin Mann’s observation, delivered in fewer than 140 characters, deserves to be framed and mounted next to every input device:

Some days, the web feels like 5 people trying to make something; 5k people turning it into a list; and 500MM people saying, “FAIL.”

If you’ve ever created anything on the web—a story, a picture, a video or an application—then you’ll be familiar with the range of responses that will result. I don’t just mean the laughably mindless babblings of the Diggtards and Reddidiots; I’m referring to that peculiar effect that sitting behind a monitor has on otherwise level-headed well-adjusted people. In the same way that some people undergo a Jekyll and Hyde transformation behind the wheel of a car, computer keyboards have a tendency to bring out the fuckwad in many of us—I include myself amongst that group.

The upshot of this effect is that criticism tends to be harsher online than if it were delivered in real life, which might just be due to the lack of . Should you find yourself on the receiving end of some criticism, having built a labour of love, I’ve put together a hierarchy of verb tenses by which you can weigh the feedback you’re receiving:

  1. Past. Advice from someone who has also built something is valuable. Their opinion is informed by experimental data.
  2. Present. If someone else is also building something, it’s worth paying attention to what they have to say.
  3. Conditional. This is the bottom of the pile. If someone describes what they “would” have done or what you “should” have done, it isn’t worth wasting your retinas on the photons of that feedback.

Although this hierarchy of verb tenses was prompted by web-native creations, it probably works equally well for film-making, plumbing, literature, dentistry, music, or just about any endeavour of the human spirit.