Older Web applications and the challenge of IE 10+

As the market share of Internet Explorer 10 increases along with the looming release of Internet Explorer 11 a growing number of web developers are realizing that Microsoft in their great wisdom (I am not against it, just wish there was an option) removed the ability to use conditional comments.

In a sense breaking every legacy application that a company might be using. For those that do not know or need a refresh, conditional comments where a way to do something like this:

<!–[if IE 8]>

<![endif]–>

Conditional comments were commonly used by developers to load a CSS files specificly for the quirks of that browser. Why? Because the rules would change for how features where handled (joys of lack of feature standardization). So one could say with conditional comments being removed in IE10 developers must now pay for the past faults. An businesses have to enforce stupid lock out rules like all PC’s can only have IE 8 or 9, or shoot me now IE6.

So what do we do about it?

The purist out there say “oh just make the changes and only support IE 10, DEATH to all other browsers!!!” To them I must ask if they have ever worked in an enterprise setting.

Firstly this is not always possible, project time lines, size of the application, and resources sometimes does not allow this to be an option. Secondly on most teams I have been on new features are more important then fixing past issues. Most of the time a legacy feature was probably written by someone else so teams avoid changing what is working for fear of breaking that code. So in essence of ROI of upgrading an application to a newer browser does not out way the ROI of implementing new features. Perfect example of why there is still market share for IE6.

I am sure this hack will probably get some angry feedback from the purist and those that think it is so easy to just waist time and money on older applications or complex ones that are slowly being refactored (large applications can not be upgraded over night, sometimes it takes YEARS).

Option 1: (Restore conditionals through changing the document mode)

Internet Explorer 10 might have some great new features; however if you have an application that must support all the flavors of IE still more then likely HTML5 is not on the radar you can set the browser document mode in a way that it only affects IE 10. This will in turn allow IE 10 to see conditional comments, it will be treated as if the browser is Internet Explorer 9.

<!DOCTYPE html public "-//W3C//DTD HTML 4.0 Strict//en">
<meta http-equiv="X-UA-Compatible" content="IE=9" />

Option 2: (Feature detection to determine which browser)

Feature detection is where we check (usually through JavaScript) if the browser supports a specific HTML/CSS feature. This is a growing tread with HTML5 and browsers implementing those features differently. Well we can do the same thing to attempt to figure out what browser a client is currently using. You might ask “Why not just use browser detection and look at the agent?” Simple answer browser detection is considered evil, very unreliable, and easy to lie to.

I found two references to two charts

Tanalin.com

IE Versions	Supported Standard Object
10+	window.atob
9+	document.addEventListener
8+	document.querySelector
7+	window.XMLHttpRequest
6+	document.compatMode

snippets.webaware.com.au

IE Versions	Find Version
10+	“history” in window && “pushState” in window.history
9+	“performance” in window
8+	“documentMode” in document
7	“maxHeight” in document.documentElement.style && !(“documentMode” in document)
6	!(“maxHeight” in document.documentElement.style)

With these two tables we can now do something like this:

// Check if this is Internet explorer
if ("documentElement" in document && ("filters" in document.documentElement || "documentMode" in document)) {
       // IE 6
       if (!("maxHeight" in document.documentElement.style)) {
               document.documentElement.className += ' ie6';

                // can load js file or css if needed
       }

       // IE 7
       if ((document.documentMode === 7) || ("maxHeight" in document.documentElement.style && !("documentMode" in document))) {
                document.documentElement.className += ' ie7';

                // can load js file or css if needed
       }

       // IE 8
       if ((document.documentMode === 8) || (document.all && document.querySelector && !document.addEventListener)) {
                document.documentElement.className += ' ie8';

               // can load js file or css if needed
       }

      // IE 9
      if (document.documentMode === 9) {
                document.documentElement.className += ' ie9';
      }
}

With this code snippet I am looking to see if the browser first is IE. If it is IE, I then start to check for browser features to determine which one I am most likely talking to. If you notice I am checking the documentMode first for IE 7,8, and 9. This is because as we saw in option one we can force the documentMode for IE. (Example: Telling IE 10 to run documentMode of IE 8).

So in the example above what ends up happening is if say IE 8 is found. It changes the html tag to look like this:

<html class="ie8">

Since CSS gradients can be a pain in IE 6, 7, and 8; we have the option now to add a change for our CSS class that looks like this:

.WorkListGrid tr.Row
{
    background: #dedede;
    background: -webkit-gradient(linear, 0 0, 0 bottom, from(#dedede), to(#ffffff));
    background: -webkit-linear-gradient(#dedede, #ffffff);
    background: -moz-linear-gradient(#dedede, #ffffff);
    background: -ms-linear-gradient(#dedede, #ffffff);
    background: -o-linear-gradient(#dedede, #ffffff);
    background: linear-gradient(#dedede, #ffffff);

}

/* Do not need to add the cross browser background sizes, this will only run for IE*/
.ie6 .WorkListGrid tr.Row,
.ie7 .WorkListGrid tr.Row,
.ie8 .WorkListGrid tr.Row {
    background: #dedede;
    background-image: url(../../img/gradientgrey.jpg);
    background-repeat: repeat-x;
    background-size: 100% 100%;
}

If the browser is IE 6, 7, or 8 it will use a gradient image file, and so we do not break any modern browser we can still implement the standard background gradient CSS parms.

In conclusion like I said in the intro this might not be best practice nor will the purist like this article, but in business there are times when developers have no choose but to do hacks and slashes to get a feature out the door. It is the way the world turns. In my opinion option two could be a good. If an application is being redesigned one feature at a time in order to modernizing it. You gain the flexibility of making changes without major features breaking.

2 Responses to Older Web applications and the challenge of IE 10+

Ross McKay says:

May 2, 2013 at 5:25 pm

G’day, in your code above, you should lead your new class names with a space so that if the HTML element already has classes, you don’t bugger up both them and your new class 🙂

document.documentElement.className += ‘ ie9’;
- chadit says:
  
  May 3, 2013 at 8:26 am
  
  fixed, sorry about that, I removed it when I was cleaning up cut and copy whitespace out of VS

Comments are closed.