read

Stuff staff hard at work on the responsive site

Like many others out there I'm sure, we've been wrestling with the question of how to support Internet Explorer 8 while still trying to create great web experiences for the majority of our audience.

We've all been through a similar experience before with IE6 and IE7, but the difference with IE8 is that it's probably going to hang around for a quite a while to come.

The reason for this is that IE8 was the last browser that Microsoft released that would work on the Windows XP operating system, and there are still significant numbers of people out there that are using these older PCs with XP installed. It also doesn't help that there are big chunks of government and other organisations that have adopted Microsoft as their enterprise solution, and use features such as ActiveX which lock them into using the Internet Explorer browser.

Because of this, the IE8 share of our browsing audience will probably appear as a long tail, declining over time, but taking a long time to drop below 1%. Our IE8 audience is currently at just under 4%, and in the past we've treated 1% as the cutoff point below which we don't aim for feature parity of our site when compared with all other supported browsers.

It is heartening to note that the IE8 share of our audience has decreased from around 5.5% over the last six months, though we expect to see this rate of decline slow a bit over time (it would, however, be nice to be proved wrong).

For us as developers and testers, supporting older browsers such as IE8 is painful in a number of ways:

  • we can't implement some of the newer CSS and JavaScript features and techniques that would provide a better experience for the majority of our audience

  • we have to spend an inordinate amount of time ensuring that our site works well in IE8. For a recently feature, we probably spent more time testing and fixing bugs for IE8 than we did for all other browsers combined, and I've previously heard developers estimating the time spent in supporting the older IE versions at around 20% of their work week

Cutting the Mustard

As a way of dealing with the IE8 overhang, we're very much interested in the technique developed at the BBC, called "cutting the mustard".

Essentially, this means when serving a page, determining whether the browser has a certain level of support and if it doesn't (i.e. doesn't cut the mustard), then that browser will receive a core experience which delivers the essential content, but is not augmented with secondary content and functionality.

There's plenty of background on how the BBC and others make use of this technique (for example, here and here), and for the BBC the core experience consists of the following:

  • Use a single column design
  • Only add core content into the page
  • Add hyperlinks to other pages that contain secondary content
  • Avoid using any JavaScript
  • Use very simple CSS

A JavaScript test will determine whether your browser "cuts the mustard", and if not, it won't use JavaScript to load any secondary content, and will rely on a core set of styles.

The original test used was as follows:

if('querySelector' in document
     && 'localStorage' in window
     && 'addEventListener' in window) {
     // bootstrap the javascript application
     }

The above works fine for treating IE8 as unsupported as was very relevant when the BBC started using this technique in 2012, but as time marches on others have figured that, for them, the definition of an unsupported browser should include IE9 and Android 4 and so use a test like the following:

if ('visibilityState' in document) { 
    // Modern browser. Let's load JavaScript
    if ('serviceWorker' in navigator) {
        // Let's add offline support
        navigator.serviceWorker.register('sw.js', {
            scope: './'
        });
    }
}

The point really is to figure out what level of browser support you're aiming for, and then determining a (hopefully simple) JavaScript test to check for it.

A vanilla site is a fast site

Some may say that the users on older browsers that don't cut the mustard are getting an inferior experience; they may not get the full user experience that they would on a modern browser, but then again if we were trying to make a user experience that was consistent across modern and older browsers, noone would be getting this experience as we either literally couldn't achieve this, or couldn't justify the resource to do so.

However, it's important to realise that what users of older browsers do get is an experience that is faster to load than it would be otherwise: there's less content to be downloaded, and devices running these older browsers are likely to be slower in presenting the page in the browser anyway.

Progressive enhancement by another name

As web developers we've been talking about progressive enhancement for a while now, and cutting the mustard is really another take on this idea. We aim to provide a core experience that any user can see, and then we build upon this to provide a richer experience where we know that the user's browser will support it.

For us, cutting the mustard / progressive enhancement ties in nicely to how we're beginning to develop our site. Like many others, we currently maintain separate sites for mobile and desktop, but we want to develop a single responsive site that will work on any device, regardless of size.

In doing so, we know that we're going to have features on the page that we will want to make available to both mobile and desktop users, but we'll also have features that we'll only want to deliver to mobile, or to desktop, and we'll be using JavaScript to pull in this content once we determine what device the page has been loaded into.

We can therefore create a page which is delivered complete with the core HTML and content that we want to serve to all devices, and this page is expected to work on all browsers, including IE8.

When we detect that the browser doesn't cut the mustard (e.g. because it's IE8), we simply won't load any secondary content, and the user will still get a fast and usable experience.

For us, as well as reducing the amount of time to develop and test, this approach provides the following benefits:

  • we can develop our JavaScript assuming that we have access to ECMAScript5 features. IE8 is only compatible with ECMAScript3, and we have to use a number of polyfills if we want to make it work like modern browsers. If we know that, apart from the cutting-the-mustard test, our JavaScript won't be running in an older browser, then we're free to use ES5 without polyfills

  • we can develop our non-core experience using CSS3 and HTML5 knowing that we don't have to polyfill / shim these

The nice thing about this approach is that everyone wins: we as developers and testers can rollout features faster; users of newer browsers get a better experience sooner; and users of older browsers get a faster experience while still being able to view the essential content.

Blog Logo

Jason Darwin


Published

Image

Making Stuff

Fairfax Media NZ Product Tech: coding at the cutting edge of media

Back to Overview