HTML & CSS
Article

Cleaning House after Internet Explorer

By Adrian Sandu

The new year started great for front-end development. On January 12th, Microsoft ended support for old versions of Internet Explorer. Millions of developers worldwide rejoiced at the news. The last vestiges of the Browser Wars that defined the beginning of the new millenium were finally put to rest.

For at least the last decade, the various versions of Internet Explorer have been the bane of web designers and front-end developers everywhere. The rise of Firefox, Opera and later Chrome showed the world that the web can be so much greater, faster and more secure. Yet, in fear of breaking the web for those who didn’t (or couldn’t) move away from Internet Explorer, we were forced to jump through hoops and bend over backwards to cater to the quirks of these legacy browsers. There is a well known pie chart image (the oldest appearance I could find was in 2007 on www.dezinerfolio.com) that showcases the feelings of the community:

Time Breakdown of Modern Web Design

Fortunately things are a lot better now. We only have to deal with the last incarnation of the Trident engine, namely Internet Explorer 11, which is already a solid modern browser on par with its competition. It is thus the time to clean house and throw away the deprecated tools, processes and techniques. Out with the old…

No More Browser Hacks

The first weapon we had in our arsenal was the browser hacks. A hack is a seemingly incorrect declaration that exploits some parsing errors in the rendering engine. It is used to overwrite the standard declaration with a value that will make the layout look and function properly on that specific browser. There were hacks that targeted single versions of Internet Explorer, while others covered multiple versions. A further classification can be made depending on the format of the hack:

  • Selector hacks: These hacks usually are used to exclude old versions of IE that don’t understand the new syntax.
  • Property/value or attribute hacks: These are the original hacks — exploiting holes in the parsing engine to target specific old versions.
  • Media query hacks: They are used to target/filter various versions of browsers (not only Internet Explorer) based on the support of the syntax for @media declarations.
  • JavaScript hacks: They are used for “browser sniffing”, detecting specific versions of Internet Explorer based on various features supported by the JavaScript engine.

The use of hacks was both complicated and frustrating. Sometimes you had to cascade several hacks one after another, as some parsing errors (that allowed the existence of the hack) were fixed in following versions without removing the rendering problem that required the hack in the first place. Let’s see a few examples of such hacks, restricted to the three versions recently retired:

/*========== Selector Hacks ==========*/

/* Internet Explorer 10+ */
_:-ms-input-placeholder, :root .selector {}

/* Everything except Internet Explorer 9 and lower */
html[lang='\
en'] .selector 
{}

/*========== Property/Value Hacks ==========*/

/* Internet Explorer 6-8 */
.selector { property: value\9; }
.selector { property/*\**/: value\9; }

/*========== Media Query Hacks ==========*/

/* Internet Explorer 8 */
@media \0screen {}

/* Internet Explorer 10+ */
@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {}

/*========== JavaScript Hacks ==========*/

/* Internet Explorer 6-10 */
var isIE = !!window.ActiveXObject;

/* Internet Explorer 8-10 */
var isIE = document.all && document.querySelector;

For a more comprehensive list of hacks to remove from your code, visit Browserhacks.

Bye Bye Conditional Comments

As we have seen above, the use of CSS hacks is messy, prone to malfunction and (for those of you who are obsessive about their code) making the stylesheet fail validation. Things had escalated to the point where, in November 2005, the guys at Microsoft stepped in and made a call to action for the demise of CSS hacks, urging developers to use conditional comments instead.

Initially conditional comments were used to load extra stylesheets for certain versions of Internet Explorer. At that time the code differences between standard-compliant browsers and Internet Explorer were large enough to make the practice a valid one. When HTML5 became a reality, this was also used to load polyfills that provided the missing support for the new features (we’ll touch this topic later in the article). While this practice was mainly used to target code for IE6–7, you might still encounter it in some legacy code. Let’s have a look at some code samples:

Conditional Comments Used to Load Extra Stylesheets

<!--[if lte IE 8]><link rel="stylesheet" href="lte-ie-8.css"><![endif]-->
<!--[if lte IE 7]><link rel="stylesheet" href="lte-ie-7.css"><![endif]-->
<!--[if lte IE 6]><link rel="stylesheet" href="lte-ie-6.css"><![endif]-->

Conditional Comments Used to Load JavaScript Polyfills

(code excerpt from the default Bootstrap starting template)

<!--[if lt IE 9]>
  <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
  <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
<![endif]-->

The main issue with this approach was that each version of Internet Explorer targeted this way made extra HTTP requests. The developers were forced to search for approaches that offered higher performance. The result was to deploy conditional comments to add extra classes to the <html> tag. This practice was a lot more popular, being used, among others, by the HTML5 Boilerplate framework. By that time Internet Explorer 6 could either be ignored or treated using graceful degradation, while the differences between the more modern versions (IE7–9) and their competition (Firefox, Chrome, Safari and Opera) were small enough not to warrant entire extra stylesheets. The few minor tweaks could be achieved due to the extra specificity provided by classes added to the <html> tag. This is the example most likely to be encountered today, as illustrated in the examples below:

Conditional Comments Used to Add Extra Classes to The <html> Tag

<!--[if IE 7]>   <html class="ie7"><![endif]-->
<!--[if IE 8]>   <html class="ie8"><![endif]-->
<!--[if IE 9]>   <html class="ie9"><![endif]-->
<!--[if gt IE 9]><!--><html><!--<![endif]-->

CSS Code Using the Extra Classes

.foo { color: black; }
.ie7 .foo { color: blue; } /* IE7 */
.ie8 .foo { color: green; } /* IE8 */
.ie9 .foo { color: red; } /* IE9 */

The launch of Internet Explorer 10 brought the end of conditional comments, as they were not supported anymore in this version. Feature detection (using Modernizr) was the new standard for progressive enhancement or graceful degradation. Only websites or frameworks that needed backward compatibility still used them, mostly to load polyfills, as we could see in the examples above.

Slim Down Your JavaScript Libraries

We have seen above how the lack of support for modern features was often plugged with polyfills using conditional comments. If your application or website is using such scripts, you can safely get rid of them now. But not every situation is as clear as this one. Let’s expand this topic a bit further, with a few relevant examples.

It is a known fact that jQuery is the most used JavaScript library on the web, with more than 53 million websites on the record (according to BuiltWith.com). jQuery was born from the need to level the playing field between browsers by covering the differences in feature support. Over time, the legacy support had reached such a level that in 2013 jQuery was split in two branches: 1.x.x maintained support for old versions of Internet Explorer, while 2.x.x dropped all the features related to Internet Explorer 6–8. The latest update on January 8, 2016, has been announced as the last one before the move to 3.x.x. Therefore you could either stay with the 1.x.x branch and jump directly to 3.x.x, or switch now to 2.x.x and get as much efficiency as possible at the moment.

There is one more thing to consider. Internet Explorer 11 and Edge have better integration of native methods (especially for DOM navigation and manipulation) that in the past required jQuery to function properly across browsers. In some cases, when the scripts can be refactored properly, it might be even possible to remove jQuery completely and make use only of plain JavaScript.

Another example is Modernizr – which we already mentioned earlier. The way this library works is to perform a set of tests for supported features and mark the result as a class attached to the <html> element. With a little bit of research (mainly on CanIUse.com) we can disable the tests designed to isolate features not supported in older Internet Explorer versions. If your page is making use only of mainstream features, with broad browser support, you might not need to load Modernizr at all.

The same approach is valid for any other polyfill script you might use. Check if the features it patches are supported in the modern browsers and get rid of it if it’s not needed anymore.

Remove Proprietary CSS Values

Once upon a time, Internet Explorer was the only browser capable of doing amazing effects in the page, due to a proprietary piece of technology called ActiveX Filters. Developers were able to do static effects (e.g. opacity), create gradient backgrounds, rotate and transform elements or do transition effects when loading a new page. While CSS3 offered standard alternatives to most these effects, ActiveX filters remained for a long time the only option available for Internet Explorer. It is not uncommon to still encounter these declarations, especially in hand-coded stylesheets. Therefore, be on the lookout for statements like the ones below, you do not need these anymore:

.foo {
  /* Internet Explorer 4.0 syntax */
  filter:filtername(sProperties);

  /* Internet Explorer 5.5 syntax */
  filter: progid:DXImageTransform.Microsoft.filtername(sProperties)";

  /* Internet Explorer 8 syntax */
  -ms-filter: 'progid:DXImageTransform.Microsoft.filtername(sProperties)'";
}

If your process of writing CSS includes the use of an auto-prefixer, then you need not worry about this topic. A good plugin will stay up to date to the level of support present in the modern browsers.

Get Rid of Obsolete Meta Tags

Internet Explorer 8 introduced a new software mechanism, called “Compatibility View”, designed to alter the rendering mode in such a way that older websites will still render properly. This was achieved with the help of a X-UA-Compatible declaration, either as a <meta /> element or through the HTTP headers. At one point this approach was even recommended inside the Google Web Toolkit. Today, now that only Internet Explorer 11 and Microsoft Edge are supported, these tags became obsolete. We can see here an example of what you have to look for:

<meta http-equiv="X-UA-Compatible" content="IE=9">
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />

Clean Up Your Custom Web Fonts

For a long time web designers were limited in their font choice. People put together numerous “web safe” font lists from the system fonts available on various operating systems (e.g. CSS Font Stack). With the introduction of the @font-face rule, everyone is now able to load custom fonts, either directly or from services like Google Web Fonts and TypeKit. Let’s not forget the plethora of icon fonts that gathered great popularity. Chris Coyier has a comprehensive entry on using @font-face in case you need to refresh your memory.

With the end of support for Internet Explorer 9 we can now safely ditch the .eot (and even .ttf) font files, together with their related CSS entries. This is especially useful if you need to manage an icon font, as the update process is greatly simplified (although more and more people recommend using SVG icons instead of an icon font).

Simplify Your Cross-Browser Testing Process

Cross-browser testing and debugging has always been a tedious process, especially when Internet Explorer compatibility was required. Over the time various solutions were found: from applications like IETester or Multiple IE. Some people used virtual machines but the main problem was that you still needed a valid OS license for each instance. Then the guys at Microsoft stepped in and offered “time-bombed” virtual machines with specific combinations of Windows and Internet Explorer. All one had to do was to choose their favorite virtualization system from the available list (currently containing Virtual Box, VMWare, Vagrant and HyperV), download the desired virtual machine image, fire it up and start working.

All these options are still available today, if you feel nostalgic and want to explain to the new kids how you had to debug your code on Internet Explorer 6 without Web Developer tools. There should be no more reason though to make them part of the normal development process.

Conclusion

Debugging code for legacy Internet Explorer versions used to be a complicated (and sometimes frustrating) process. We memorized the most common browser bugs and their counters. Position is Everything and Quirks Mode used to be at the top of our bookmark list. Fortunately, as the web continues its evolution, we are able to leave those days behind us and discard the obsolete tools and practices. Now it’s the time for a thorough house cleaning.

Adrian Sandu
Meet the author
Adrian is a UI-oriented front-end developer and UX enthusiast. When he's not chasing pixels across browsers, he loves playing video games, visiting new places, and improving his photography skills.
  • https://www.wpperformancepro.com/ Joe Fletcher

    Us web developers have been waiting for this moment for a long time! I can’t believe it’s finally here. Time to rip out all those IE hacks. Good riddance. I’ve probably dropped modernizr for good.

  • Adam

    > We only have to deal with the last incarnation of the Trident engine, namely Internet Explorer 11

    Depending on who you’re referring to when you say “We”, this statement may not be true. Have a look at this tweet:

    https://twitter.com/chriscoyier/status/686923598704021505

    In my opinion, dropping support for Internet Explorer is only OK to do if you are OK with the consequences. If a site has a significant number of Internet Explorer users or if a site makes a significant amount of money through purchases and/or ad clicks made by Internet Explorer users, the site owner will likely want to continue supporting Internet Explorer regardless of whether or not Internet Explorer is supported by Microsoft.

    • http://www.adriansandu.com Adrian SANDU

      Hi Adam,

      Plans for dropping support for oldIE should have been made the moment Microsoft announced their decision. Browser usage for each website should be indeed the top argument for the decision of dropping support. If the share of oldIE is still significant, then perhaps a transition period should be introduced before support drop, allowing the users to upgrade. Also it depends if the support rests on functionality (like proprietary JavaScript code) or just aesthetic.

      It also falls on us to educate the users on the advantages of renouncing to old browsers, especially after the support period has ended, as they are more vulnerable to attacks. This is not a new argument, but one that has started from the moment people started abandoning IE6.

      The purpose of my article is not to tell you whether to drop the support or not. This is a decision that must be considered on a case by case base. But once you’ve decided to go ahead, you only have to follow the checklist I provided.

  • fledder2000

    “We only have to deal with the last incarnation of the Trident engine,
    namely Internet Explorer 11, which is already a solid modern browser on
    par with its competition.”

    Yeah, right. I recently worked on an ecommerce site that still had over 150,000 monthly IE8 users. As it is an e-commerce site, support cannot be dropped. Please don’t speak in the past tense about old IE, it is still here for many companies to have to support, for years to come.

    Furthermore, even IE11 is far behind the more modern web features, definitely not on par with the competition, which is speeding away.

    To end positively, yes, things got better, but it’s not as positive as you are presenting in the above statement. Not to all, at least.

    • http://www.adriansandu.com Adrian SANDU

      Hi and thanks for adding your thoughts.

      I will reiterate here one of my previous replies: the decision whether or not to drop support is not the subject of this article. That process is unique to each situation and depends heavily on the specifics of each case. I am simply offering a check list of things to look for AFTER the decision has been taken to drop the support.

      Regarding legacy support, if it must still be maintained due to the user base, it’s our duty as developers to push for the inclusion of an update suggestion. Talk to the person in charge about including an unobtrusive message telling the users with old browsers that they put themselves at risk. There are plenty of websites dedicated to the education of users on the benefits of upgrade, like browsehappy[dot]com, outdatedbrowser[dot]com or updateyourbrowser[dot]net.

      This sort of discussion is almost a decade old so I won’t try and repeat the arguments that were used all these years. Nor will I try to convince you further of the necessity of this education process. I will have to dip into my collection of Internet quotes and say that if we are not part of the solution, we are part of the problem.

      • fledder2000

        I agree with those answers and that approach, I was merely responding to this statement:

        “We only have to deal with the last incarnation of the Trident engine,
        namely Internet Explorer 11, which is already a solid modern browser on
        par with its competition.”

        This statement suggest it as a fact that “we” don’t have to deal with old IE. The wording invites comments like mine to object to that.

        Anyway, enough word games. As for educating users, it’s not as easy as it seems. We do that (by showing upgrade notifications bars and a more basic rendering), but there is this hardcore group that just does not move. At all. 80% from China.

        • Dennis Parrott

          the Asian non-updaters are 99.9% on pirated OS software that CANNOT be updated. people who want to get rid of their support code for old versions of IE better pray that there is a wave of radical computer failures that take out all those old boxes and they all buy new ones with a non-pirated OS…

  • http://appsapps.info/ app

    Nobody has yet provided a means for embedding a browser into a Windows desktop application quite as easily as Microsoft has with Trident, and there are a lot of applications with Trident embedded into them that are not going to go away any time soon.

    Microsoft has not yet provided an alternative for these applications to migrate to. Fussing with integrating Webkit or Gecko into your desktop application really isn’t as easy and can not realistically be considered an alternative to the simple drag & drop Trident option that has been available for eons, in tools such Visual Studio, Delphi, and C++ Builder. By embedding Trident, you eliminated the need to keep providing updates every time there was a security patch released for Gecko or Webkit. Your embedded Trident based browser was self-updating, whenever the user installed an IE update.

    And just how prevalent is the use of the Trident engine in applications which are not considered the Internet Explorer desktop browser, as you know it?

    Off the top of my head, I can name a few browsers & RSS readers that still use it:

    – AOL’s desktop software (yes, there are people still on dialup that still use this and it’s still available on AOL’s website)
    – Maxthon browser (the devs have plans on migrating to webkit/Chromium in the next version, but their users are staging a revolt over it)
    – Newzie RSS reader (still one of the best, IMHO, and while it does have a Gecko option, you can only use an outdated Gecko version with it and the user has to set that up themselves, and it’s not that easy to get it working correctly)

    Not to mention the plethora of smaller freeware and indy apps (even I wrote a few desktop apps that used it), and very expensive custom developed proprietary enterprise applications.

    Just because Microsoft is dropping support for “IE” doesn’t mean they are completely dropping support for the Trident components of their OS that makes these other applications work. Windows users just won’t be able to launch an application called “Internet Explorer” from their desktop or receive updates for “Internet Explorer”. They will still be able to launch those other apps with the Trident engine integrated into them, and those components of their Windows OS that makes those other apps work will still receive security updates.

    Because if Microsoft doesn’t, enterprise customers that have invested a ton of money into the development of proprietary software they need to run their business, that integrates the Trident engine, will all jump ship. If they are going to have to invest another $50,000+ to have their proprietary software rewritten to use a different browser engine, they might as well move to another OS while they are at it, such as Linux, or not upgrade to a newer version of Windows (which isn’t free for enterprise customers).

    And Microsoft knows that, so they won’t remove those Trident based Windows OS components. Those enterprise customers and those that develop software for them are their bread & butter. Can you imagine Microsoft telling their enterprise customers “We are going to break all your apps if you upgrade, but we expect you to upgrade any way, and pay us a lot of money for that, and then pay a ton more to have all your apps rewritten to work with our new Windows OS”?

    So, if you have site visitors using any of the apps I mentioned above, or you develop stuff for use in these enterprise apps that use the Trident engine, you’ll be supporting “IE” for a long, long time to come.

    • http://www.adriansandu.com Adrian SANDU

      Hi and thank you for your thoughts!

      You are indeed right with your comment. The corporate sector is a world apart and the sort of integration you are talking about is not something that can be easily replaced. The focus of my article is the wide web, the Internet the average Joe or Jane uses every day. This is the place where we can and we must promote evolution.

  • Lasse Rafn

    But.. dropping support does not mean that people stopped using it.. I still see people using IE, and even picking IE above Edge.

  • Lasse Rafn

    But.. dropping support does not mean that people stopped using it.. I still see people using IE, and even picking IE above Edge.

    • http://www.adriansandu.com Adrian SANDU

      Hi and thank you for commenting. Please check my answers to the other similar comments.

  • April Hoyt

    YAY!!!!

  • http://www.artbyarjan.com Arjan Oosthoek

    The Microsoft article says: “only the most current version of Internet Explorer available for a supported operating system will receive technical supports and security updates”.
    Since the oldest, supported operating system is still Windows Vista, isn’t Internet Explorer 9 the ‘most current version’ for that OS?
    This means we’re still stuck with outdated browsers…

  • JS

    Unfortunately, even Microsoft itself can’t seem to let go of old practices. Case in point, SharePoint, which requires Active X still for some of its components, and as such will not work in Edge or in Native mode of IE11(edge). It still requires enterprises to place their SharePoint Sites in Enterprise 8 mode to run effectively. What I am unclear is, if a site is in Enterprise 8 mode, whether front-end developers still have access to HTML5 or CSS3, or because of Enterprise 8 (IE8 emulation) it negates any use of those modern elements, and we are still left to design sites to the IE8 level only?

Recommended

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the lastest in Front-end, once a week, for free.