Part of developing for the web is supporting an ever changing, advancing collection of technologies and methodologies. Looking to the past is often necessary to maintain and update things – I even wrote a blog post with some simple tips for older browser support. But there’s one browser troublemaker who isn’t as easy to accommodate: Internet Explorer.

The question of supporting older, more awkward versions of IE is not a new one. Microsoft’s flagship browser has been a thorn in the side of web developers for many years with its frustratingly “unique” way of displaying web content. Drastic changes between versions and a poor track record for implementing new features (though this seems to be improving with newer releases) have meant that Internet Explorer – a browser often confused with the actual Internet itself by some older users – has been the subject of debate for a long time.

Recently working on a site that required IE8 support reminded me that for new developers trying to figure out their scope for the first time, or people still keeping IE support alive (and considering stopping), it can still be an ongoing discussion. Newer versions of IE are becoming a lot friendlier to develop for, which is great news. But the legacy of Internet Explorer as the default PC browser for many years, bundled with versions of Windows, is its curse. The PCs of elderly or less tech-savvy individuals may still be running a version of IE whose browser rivals have long since died out.

So if these relics of the past still exist, should Internet Explorer 8 be taking up your time?


Time is money, friend

It’s unlikely that, apart from possibly at a dodgy car boot sale, you won’t see the latest film releases on VHS any more. Technology has moved on, and so the same goes for browser technology. Old formats are abandoned because it’s not cost-effective to continue supporting them alongside newer, more popular formats.

Websites are no different. There are new toys to play with, tools to build great web-based experiences with, and the widely-used browsers that support them. Continuing to make modern sites backwards-compatible with older browsers can be a massive drain on resources. The further that web technologies advance forward, the more polyfill techniques or entirely separate alternatives need to be developed. This eats into the time and money that might otherwise be spent on more worthwhile development, or simply makes projects lengthier and more expensive.

As a developer, I enjoy making things as fresh and exciting as they can be. Having to reign those ambitions back in, or spend just as much time making them degrade gracefully as I did making them in the first place, can be hugely demoralising. I’ve personally been in numerous conversations where an exciting feature has been cut because of older browsers. It’s usually not because it would be impossible to do, but the amount of work involved to prop-up a browser like IE8 just isn’t worth the investment.


Fewer prefixes for easier fixes

Supporting older browsers isn’t always a hassle, and I do make efforts to try and include small fixes where I can. Browser prefixes (sometimes called vendor prefixes) are an extra few characters at the start of some additional CSS properties for a specific browser. When browsers start supporting a property before it becomes standardised, these prefixed properties produced a similar result. This is most common in Firefox (with the -moz- prefix) and Safari or Chrome (with the -webkit- prefix).

This means that supporting those browsers becomes much easier. Adding an extra line or two can add support for a few older versions with a few extra keystrokes. Solutions like this support quite a small percentage of browsers, but for such a minimal effort it’s a really easy way to tidy up your layouts for more users.

-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;

Internet Explorer does have a few -ms- prefixed properties, but there aren’t nearly as many as the others and they’re not always for some of the most common CSS properties (such as border radius). These oversights and lack of convenient alternatives help make Internet Explorer so time consuming to compensate for.


Keeping the nightmare alive

From another perspective, continuing to support problematic browsers also contributes to their longevity. Many users aren’t aware that a 5-year-old browser is considerably ancient in relative terms. They probably don’t realise that some of the issues that they’re likely to see on less forgiving sites, who’ve written off their browser already, can be easily solved.

While I’m keen for things to move forward, dropping support can sometimes be problematic for those users who remain unaware. Punishing them for their browser choice is a bad move – your IE8 site users might simply stop visiting if the layout starts looking broken in their browser, as they might not know any different.

The friendlier option is to add an informative message, in addition to the . This is something I’ve mentioned before, and it’s far more informative than letting some of your site users figure out the reason for the broken layout themselves.

The New York Times recently dropped support for Internet Explorer 8, and this tweet from their Director of Web Development, Reed Emmons, is pretty illuminating:



By using a deprecation notice with a helpful link to, a significant portion of their visitors were able to make an informed choice about a better browser in just 24 hours. I wouldn’t be surprised if almost all of those IE8 users made a switch in the near future. And with 31 million unique visitors a month (source), that’s a benefit that countless other sites will share as their users move to an updated browser.

It’s clear that with a little push in the right direction, helping web users be a little more educated about their browser choice is a good thing for all of us.


Exceptions, of course

There is a reason I added the “unless asked” caveat to the blog title, however. As I mentioned previously, browser support can depend on your audience. Cases of IE8 in the wild may be few and far between, but if your own environment has an unusually strong population then it might be worth accommodating. This is particularly true for web sites that have a community of older users, or large businesses that may rely on a particular browser version for web-based tools and intranet.

Offering support to older browsers is a good gesture in general, and there’s probably a few good reasons out there to support Microsoft’s troublesome offspring once in a while. But unlike its peers of a similar age – Firefox and Chrome, with their browser prefixes and quicker updates – it almost doesn’t want our help. In the name of progress and to help our fellow web users move forward, sometimes it’s better to educate than accommodate.

If it’s right for you, spend 5 minutes coding a “Hey, listen” message to your remaining IE8 visitors, rather than hours tearing your hair out when you could be coding something great.