Browser Support - Mission Impossible?

Anyone who has worked with or for (or against) a digital/web agency has probably encountered issues with browser support. When Luminary got started (sorry, we had to say it!) the better part of 14 years ago, Windows 98 was the latest and greatest operating system, and came packing Internet Explorer 4. Its biggest competitor was Netscape Navigator.

The browser battleground is now far more diverse, dynamic, and competitive. Multiply that by the factors introduced by the range of web-browsing devices out there today, and suddenly browser support starts to look terrifying to the humble web developer.

In this post I’ll look at the current browser situation as it affects web developers, and attempt to explain how we go about browser support, or more correctly, how and why we don’t!

So what exactly is a browser?

A few years back, Google hit the streets in New York to ask the people that question, with hilarious results:

Simply put: a web browser is an application that allows you to browse the world wide web.

Most reasonably tech-savvy people have heard of these:

The more nerdy among us have heard of these:

1. Google Chrome
2. Microsoft Internet Explorer
3. Mozilla Firefox
4. Apple Safari
5. iOS Safari
6. Android Browser
7. Opera
8. Chrome for Android
9. Konqueror
10.  Lynx

A browser actually consists of many parts:

1. Webkit (used by Chrome, Safari and the Android Browser)
2. Gecko (used by Firefox)
3. Trident (used by Internet Explorer)
4. Presto (used by Opera)
1. The JavaScript engine
2. The User Interface (confusingly also known as the "chrome")
3. Plugins (such as Adobe Flash or Java)
4. Extensions (such as Firebug or Skype)

Any one of these elements could have an effect on how a website is displayed, without even taking into account the operating system and screen.

This makes it extremely complicated to support browsers!

Browser share

What percentage of users are using which browser? It's very difficult to get a good picture of browser share, because it varies by so many parameters.

For example, in February 2013 when this post was being written:

Location

• China is still rocking 21% IE6, compared to 0.8% in Australia 
• Australians love iPhones!

Industry/sector

• Government clients are often restricted to using the version of IE installed on their PC

Age

• Older users are more likely to be on their PC’s default browser, or an iPad

Warning: charts like the one above probably don't help

Basically, there is no reliable, across-the-board measure of browser share. It needs to be looked at with fresh eyes for every new situation. Are you building an intranet for a government department with IE8 installed on every PC, or are you building a design-focussed blog targeted at young graphic designers?

The situation

We regularly receive requests such as this:

"Can you please ensure the website displays correctly in all browser and operating system combinations?"

Unfortunately, in most cases, the answer is no! There are a huge number of OS/Browser combinations, especially when you consider different versions of the same browser. There are literally hundreds of combinations, and even that is before considering emerging platforms such as Windows 8 (IE10+) and Windows Phone.

The problem with versions
... or more specifically - version numbers

The following stats were prepared on 6 August 2012, when I first presented the subject of this post, but I’ve kept them for a reason! The stats analysed were of a very highly trafficked Australian website. I’ve listed the overall share of each browser, the current (up to date) version number of that browser, the oldest version that still represents a significant portion of visitors ("popular") and the oldest version people seem to still be using ("still alive").

At the time of writing this blog post in February 2013, these numbers have already changed dramatically. Just looking at the most popular three browsers - the current version of Chrome has increased by four from 21 to 25, Firefox has gone up by five from 14 to 19, and IE10 has officially been released with Windows 8. Just about every number in that chart from nine months earlier is already out of date. In fact, there’s a decent chance that by the time you’re reading this blog post, these corrections I'm discussing are already out of date!

So what the hell is going on?

The mathemagicians among you will have noticed that this version number explosion can't have been going for ever. We can blame Google Chrome for setting the trend of rapid releases.

"The concept of rapid releases established by Google Chrome prompted Mozilla to do the same for its Firefox browser. On June 21, 2011, Firefox 5.0 was the first rapid release for this browser, finished a mere six weeks after the previous edition. Mozilla created four more whole-number versions throughout the year, finishing with Firefox 9 on December 20, 2011."
http://en.wikipedia.org/wiki/Browser_wars

Release Cycles:

• Chrome releases a new major version every six weeks
• Firefox releases a new major version every six weeks
• IE was slow, but now plan to release new versions more rapidly
• Safari releases a new major version approximately once per year
• Opera releases a new major version approximately once per year
• iOS releases a new major version approximately once per year
• Android releases a new major version every six to nine months
• Chrome on Android roughly follows Chrome on desktop, so every six weeks

If we combine these numbers, there's a new major version of a widely-used browser, around once a fortnight on average. This is shorter than our shortest project timeline, meaning it is practically impossible to guarantee support at launch for specific browser versions when writing our proposals.

So which browsers do we test in? Short answer: it depends.

Each project is likely to have different requirements. We research the client's and project's needs, using a variety of tools and guides:

1. Current stats, dominant browsers, unexpectedly well-represented browsers
2. Trends - is mobile increasing rapidly?
3. User interviews
4. Workshops/aims/goals
5. Responsive design?
6. Importance of design elements
7. Complexity
8. Mobile
9. Shelf life

Limitations

There are some things we avoid when committing to a set of browsers to target and test against, and for good reasons. For example:

1. We generally try to avoid the word "support", when applied to third party software rather than your website. When referencing browsers, we prefer more accurate terms such as "tested in" and "works well with".
2. We don't commit to all future versions of a browser (the dreaded '+' character)! For example: "Your site will work perfectly in IE7+" - this means we’ve committed to testing in IE11, IE12, and so on, which is impossible without an appropriately fitted out Delorean.
3. We can't blindly commit to building for all mobile devices. There is amazing diversity within the mobile space and new platforms are being released with alarming frequency. We state which devices we're targeting.
4. We don't assume your desktop design will "just work" on an iPad, regardless of what Apple will tell us. We explicitly state iPad as a separate platform, and test for it.
5. We don't suggest or imply that the site will look identical and work identically in all browsers. Nowadays with mobile devices, retina displays, and responsive web design, we embrace the concept of responding to restraints, rather than fighting against them. But that's a whole blog post on its own!

What CAN we do to cover as many browsers as possible?

This all sounds very restrictive so far. Obviously we can't just put the headphones on, turn up the music and build for only the latest version of Chrome. We try to ensure that sites work well in as many browsers as is feasible, in a number of ways:

Luminary's ever-expanding test suite

(Look out for a dedicated blog post soon on our testing suite!)

1. Writing good code! We endeavour to write strictly correct, standards-compliant markup and adopt new, backward-compatible technologies such as HTML5. In addition to future-proofing the site against all but the most obscure browser bugs in future versions of browsers, it also helps to minimise cross-browser issues. As an added bonus, it goes a long way towards helping our sites meet WCAG 2.0 accessibility guidelines.
2. Researching our clients' requirements, and testing appropriately. By digging deep into an existing site's statistics (such as Google Analytics), we can build an excellent picture of who (and what) is accessing the site. We can then build a test suite that comfortably covers the vast majority of anticipated users of the site.
3. Providing a useable experience, even for non-tested browsers. Following on from point 1 about good code, we like to ensure that the site at least works on all browsers. This way even if someone visits on an obscure browser we weren't anticipating, there's still a good chance they can get what they came for. A simple way to test this is to try to use the site in a text-only browser!
4. Providing our developers with an exhaustive test suite. At GS HQ, we have all our bases covered when it comes to testing on all sorts of obscure platforms. In-house, we have machines running Windows XP through to 8, OS X, Retina, iOS phones and tablets, Android devices galore, Windows Phone, and even a Blackberry Playbook thrown in for good measure. For the most obscure situations, we have virtual machines and emulators that can simulate almost any environment we can think up.

So... come on... which browsers do you support?

Because of all of this - Luminary has no standard set of browsers and versions that we target and test in. What we do have is a starting point to help us put together a list for a project, which we change specifically for every proposal we send out. If you're a client of ours, you might have seen something like this in your proposal:

We will test and ensure that your site works well in these common Operating System standard browsers:

• IE 7-10
• Chrome*
• Firefox*
• Safari 5-6
• Chrome*
• Firefox*
• Safari

* Chrome and Firefox employ a "rapid release cycle", which means a new version is released approximately every six weeks. We will test and ensure that your site works well in the latest current stable release version at the time of Luminary's testing and quality assurance.

In Summary

In the the last few years, the browser and device landscapes have changed dramatically. It's no longer IE versus Firefox with Chrome sniffing around. We now have to contend with literally hundreds of different combinations of platforms, operating systems, browsers, JavaScript frameworks, and their different versions and features. The notion that one can implement a feature and simply "test across all devices and browsers" is now approaching an impossibility.

The best way to approach this situation is to embrace it. Accept that there are myriad combinations of device, platform and browser, and look to employ best practices and emerging techniques such as standards-compliance, responsive web design, to try to ensure that your product works in as many situations as possible. Focus on quality and don't tolerate specific browser hacks. Research the project's specific requirements, and pick your battles. Follow the principles of graceful degradation and progressive enhancement to provide a useable experience for all browsers, not just those you're targeting. Build up a test suite and test, test, test! And crucially, communicate clearly so that everyone is on the same page.