Cutting the Mustard

Browser testing or “support” has always been a subject of contention; the community has written time and time again defining what is meant by “support”. In essence, we usually mean a list of devices and browsers that we have tested to ensure what we’ve built works for the end user. This can get a little tricky with the number of combinations of Operating Systems (OS) and browsers that are available. Throw on top the explosion in devices and you have a pretty long “support” list! To help address this issue, we focus on the most popular OS/device/browser combinations. This is where analytics play a crucial part in ensuring our testing covers the majority of scenarios.

But what about the minority? That 0.3% of visitors using Internet Explorer 6 for example. Well we could ignore they exist, like most of the web does, or we could provide a fairly basic experience. Functional, but basic. We don’t want to overload them with polyfills or spend countless hours adding conditional styles or hacks. Besides, that’s usually the lowest priority on the backlog. Instead of this endless testing and polyfilling, which ultimately invokes the law of diminishing returns, we use a simple cut-the-mustard technique to ensure we provide a basic but functional experience for those users.

(Image credit: Dennis Skley)

Cutting-the-mustard will often encompass several tests to provide varying levels of support for browsers. This can include testing for things like SVG, Canvas and localStorage support. If the tests fail, a fallback will be in place if required, otherwise the functionality will degrade gracefully.

Tools like Modernizr are great for feature testing browsers and allow us to provide alternatives for when a feature test fails, but what about that 0.3% that will fail almost everything? The really old browsers. We don’t want to waste time writing endless feature tests only for them to end up with a broken experience – The only thing worse than an ugly website is a broken website.

We take accessibility very seriously and progressive enhancement sits alongside that quite nicely. So we know that the underlying HTML of the sites we build are well structured and semantic. At the same time, everything we build is also responsive by default. This gives us a nice point at which to draw the line, as we know that a high proportion of browsers support media queries. Therefore our cut-the-mustard test is based on testing for media query support.

We use media queries in the CSS to separate advanced styling and layout:

// Basic styling i.e.: normalize and typography

@media only screen {
     // "Advanced" CSS for browsers that support media queries
}

Along with a Modernizr test in the JavaScript to separate progressive functionality:

if (Modernizr.mq('only screen')) {
    // Initialise functions and plugins
}

This simple test ensures that only browsers that support media queries get the “advanced” CSS and JavaScript. There are of course other tests and fallbacks we might have inside these two things for the more micro-level feature support, but this is the big one.

If the browser doesn’t support media queries it will get a simple, yet functional, page allowing those users to access the content. Does it look beautiful for that 0.3%? No. But is it functional? Yes.

Using this cut-the-mustard test to give us our baseline allows us to spend more time on enhancing functionality for the majority of users; safe in the knowledge that we are providing a functional experience for the minority of visitors. This can also be financially beneficial to our clients as it keeps our development time and costs down.