Lines in the Sand

A new site, Break Up with Internet Explorer 8 by Humaan, has been making the rounds on the Interwebs of late. It’s cleverly done and an attractive site, but I don’t really agree with the premise:

Join the intervention and stop supporting IE8. It’s time for an upgrade.

The reality is that some users don’t have control over the browsers installed on their computers and IE8 may be the best they can muster. Most of us have had the luxury of moving on, but they haven’t. Does that mean we should banish those users from our sites by treating IE8 like that ex who just won’t take a hint? I don’t think so.

Instead, we should approach this problem rationally. Be the bigger person. Call it support vs. optimization, call it cutting the mustard, call it what you will, but by understanding how browsers work, we can reduce our own development headaches and serve more users in the process. Yes, even when they use aging browsers like IE8 or IE7 or (gasp) IE6.

When it comes to HTML and CSS, browsers ignore what they don’t understand. It’s why you can use the section element and the content will still be exposed in Lynx. It’s also why you can use RGBa without IE6 collapsing. Fault tolerance is a really powerful tool and is the foundation of progressive enhancement in HTML and CSS. (In JavaScript things are a little more complicated… we have to use feature detection.)

A simple way to rid yourself of IE8 related headaches is to embrace the idea that web pages don’t need to look (or behave) the same in every browser and look for ways to achieve this while still providing access to your content and tools for less-capable browsers and devices. For example:

<link rel="stylesheet" href="simple.css">
<link rel="stylesheet" href="complex.css" media="only screen">

This simple stylesheet setup will deliver only the simple.css file to browsers that are incapable of understanding media queries. Browsers that do understand them will get both stylesheets. Media queries support is an easy line in the sand we can draw because lack of media query support is in fact the first media query.

Once you’ve done that, it’s as simple as putting all of your advanced styles in the complex.css file. No drama.

On the JavaScript end, you can draw a line in the sand too. Let’s say you don’t want to spend your time debugging JavaScript in IE8. You can just skip it using Conditional Comments:

<!--[if gte IE 9]><!-->
<script src="not-for-ie8.js"></script>

Using an approach like this avoids delivering the contained JavaScript files to IE8 at all, but all other browsers will see them.

If that’s too drastic, use feature detection in your JavaScript files to determine if it is safe to rely on a particular method or capability. Program defensively.

Honestly, I’ve found that approaches like these lead to fewer grey hairs and a lower overall stress level. They make me a happier developer and let me concentrate on building for the future rather than worrying about the past.

But it’s not about breaking up with IE8, it’s about having a realistic and honest relationship with it.


Note: These are comments exported from my old blog. Going forward, replies to my posts are only possible via webmentions.
  1. Alfonso Gómez-Arzola

    The point you make re: embracing variety in how a website behaves or is displayed in each browser is very important. That print design mentality of controlling every aspect of a communication piece is incredibly persistent. I think it’s probably due to a design process that has yet to embrace a progressive enhancement approach. In my experience, mobile-first and progressive enhancement are viewed by many teams as implementation concerns and not really design concerns, so you end up with mock-ups and prototypes that are all about the higher-end devices. This inevitably leads to a compromise-focused approach to supporting less-capable devices, so even if designs are implemented using mobile-first and progressive enhancement, they end up being a limping cousin of the original mock-ups, and not a direct result of designing bottom-up.

    I do have one question: Considering that browsers ignore what they don’t understand in our HTML & CSS, and that this is by design, why wasn’t JavaScript, which has its origins in the web, built this way too?

    1. Aaron Gustafson

      Great points Alphonso!

      To answer your JS question: Since every JavaScript we write is technically a program, the code must be downloaded, interpreted, and executed as such. When you write a program in any language with the expectation that a particular method or function will be available and it’s not, the program will throw an error. HTML and CSS are not programing languages and were designed to be more forgiving, unbound by the same constraints. XML on the other hand (and HTML served as XML) will throw an error if your markup is malformed. See also: