Internet Explorer fallbacks

My selfie

James Turner,

Tags: CSS HTML

A site like Responsive Web Design, beautifully designed as it is, shouldn't be the inspiration for discussing something as, well, naff as this week's topic. What is this naffness that has piqued my attention? Once again, it's something from the <head> section: the dreaded fallbacks for old versions of Internet Explorer.

I'm too late to the web design party to care that much about the history of Internet Explorer and the horrors that it's inflicted on my more experienced colleagues over the years. It's enough to say that I probably have at least three ageing web design books on my shelves in which the authors relate their war stories about designing for old versions of IE. Designing for Web Standards (3rd Ed.) (www.amazon.com) by Jeffrey Zeldman manages this without being too laboured.

Skip to navigation

Today's Relevance of Fallbacks

I get the sense, through the books, blogs, articles and podcasts that I consume, that this issue is becoming less of a problem as time goes by. So, is it still something we need to worry about today?

Before I started learning web design, when I was still a “muggle”, I'd heard that IE wasn't the best browser, but I didn't understand why, and I wasn't that interested in changing. At that time, if a website looked awful, I'd have been inclined to blame neither the browser nor the designer of the site (since I never really spent that much time thinking about where websites come from). No, I would have blamed the corner-cutting cheapskates who owned the site, also known as ‘our clients’. I wonder how many people there are like I was, who don't have the first clue about the pitfalls of old browsers. How many families have a dust-covered PC in the corner of their living room with IE8 or earlier, at which they curse as they struggle to book their holiday or buy their children's Christmas presents?

It's not just private users, either, who have to live in these Dickensian conditions. I recently attended a talk at which someone was asking for advice about a pretty serious problem related to IE. In brief, a design company had developed a web app for a client using AngularJS. The app was to be used by the client's employees in-house. The problem was that all the client's employees were stuck with IE8 on their PCs and since December 2013, AngularJS no longer supports IE8 (can't get this link to behave, sorry; go to the search bar and search “AngularJS 1.3: a new release approaches” from 14 December 2013). So, the app worked really well, just not on the client's devices.

It could be argued that the designers should have checked which browser the client was using. That hindsight doesn't make the problem go away, though—they still need to find a solution. Should the client update the browsers on all of its PCs (not a small task for a medium-sized company with 200+ employees)? Should the developers of the app go back to the drawing board? As one participant of the discussion pointed out, someone is going to lose either way. Anyone, particularly me, could find themselves in this mess, so they have my deepest sympathy.

From this admittedly anecdotal evidence, I suspect that for the time being there are still a lot of people out there who use old versions of IE. The web designer's unfortunate job, then, is to figure out, through analytics, what proportion of a project's target user base uses old versions of IE, and whether the cost of including fallbacks in a project outweighs the cost of not doing so.

Skip to navigation

Fallbacks in HTML

In order to deal with the differences in the way Internet Explorer displays a web page, Microsoft built in a back door for web designers to include IE-targeted markup by using conditional statements in comments. For example:

<!--[if lt IE 9]> MARKUP FOR IE8 AND EARLIER GOES HERE ![endif]-->

lt means ‘less than’ and IE 9 means version 9 of Internet Explorer. This line tells the browser to include whatever markup is inside the start and end tags only if the browser is IE8 or earlier.

In this article, Conditional Stylesheets vs CSS Hacks? Answer: Neither! (www.paulirish.com; originally written in 2008, but updated several times up to 2012), Paul Irish covers in some depth how to exploit this feature of IE. Specifically, he advises adding classes to the <html> element conditionally, and then adding styles to those classes and their child elements in CSS. As of January 2012, his suggested markup is:

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

In short, three classes (.lt-ie7, .lt-ie8 and .lt-ie9) are applied to the <html> element depending on the version of IE, and then styles are added in CSS. The final line is some kind of hack that magically avoids a number of highly technical problems, which I don't really understand are beyond the scope of this post.

The markup in Responsive Web Design is very similar:

<!--[if IE]><![endif]-->
<!--[if lt IE 9]>  <html lang="en" class="oldie ie"><![endif]-->
<!--[if IE 9]>     <html lang="en" class="ie ie9"> <![endif]-->
<!--[if gt IE 9]>  <html lang="en" class="ie"><![endif]-->
<!--[if !IE]><!--> <html lang="en"> <!--<![endif]-->

This markup creates three classes: .ie for all versions of Internet Explorer, .ie9 for Internet Explorer 9, and .oldie for versions 8 and earlier. (Again, the first and last lines presumably summon the browser fairies to do their magic.) These three classes are then styled in CSS.

Skip to navigation

How to style IE fallbacks in CSS

As it turns out, the CSS for Responsive Web Design doesn't use the classes .ie or .ie9, just .oldie. This suggests to me that the designer of the site set these classes up in the HTML prospectively, and then only used them after testing in versions of IE. That's interesting for me, because I often think about the methods designers use to build their sites.

At the risk of infringing copyright (sorry, Ethan and Karen), here is the CSS markup for the .oldie class:

.oldie .logo img{
  width:inherit
}

.oldie .nav li{
  display:inline-block;
  width:44%
}

.oldie .page{
  max-width:30em
}

.oldie .sect-workshop .intro .open{
  border-bottom:1px solid #CCC;
  padding-bottom:1em;
  margin-bottom:1em
}

.oldie .sect-workshop .intro .more li p{
  font-style:italic;
  width:90%;
  max-width:100%
}

.oldie .sect-workshop .intro .more ul{
  border-bottom:1px solid #CCC
}

.oldie .bio{
  margin-bottom:2em;
  width:90%;
  max-width:100%
}

.oldie .bio h2{
  text-align:center
}

.oldie .bio img{
  margin:0 auto;
  width:60%
}

.oldie .client-list li{
  margin-right:3%;
  width:30%
}

The first thing to note is that the elements styled here are all children of the html.oldie container. So it's not necessary to style the <html> element itself. There are a lot of rules for widths, padding, margins and alignment, particularly on <ul> and <img> elements. Although there's nothing that cries “this is how to deal with IE”, this is a good start.

Finding a definitive, up-to-date list of issues and workarounds is tricky. In my research, I came across a few articles—some quite old—on the specific problems IE has with HTML and CSS, and how to solve them:

After 17 years, it seems things are only just beginning to change!

Skip to navigation

Conclusion

This feels like a story without a satisfactory ending, so I may need to return to it later on. For now, though, I'm happy with what I've found. Paul Irish's preferred way to deal with IE is to add classes conditionally to the <html> element, and these classes can be styled in CSS. Also, rather than preempting the way IE will behave with a site, it may be better to set the .ie classes up and then style them if need be during the testing phase of the design.

Skip to navigation