February 25, 2016

The Wonderful World of Browser Support

Several windows on the side of a building
While it's important to ensure that content is viewable on as many browsers as possible, supporting archaic browsers often means an increased budget to accommodate a consistently decreasing number of users. At Fuse, working with our clients to outline browser support helps ensure they understand the implications of support levels across a variety of platforms, and prioritizes development of critical project features.

When discussing a project with a client, we find it is important to ensure that all parties involved understand what browsers will be supported, and what happens on those which are not.

Clients may have a general understanding of what browser support entails, but it can lead to incorrect expectations about what a project's supported browsers are. Even if browser support is well understood there are many variables between platforms, features, fallbacks, and more that should be discussed at the outset of a project.

If browser support is not discussed and agreed upon, a number of problematic events could occur through the course of the project:

  • Clients may view the final website on a browser they expected to be supported but was not developed for, leaving us to go through the entire codebase to include fallbacks, alternative techniques, and so on.
  • The decision to support additional browsers after development has started may require backtracking through completed code, which will affect the timeline and potentially the budget as well.
  • The project may be built for browsers which are not relevant to the client's actual user base, leaving the majority of visitors with incomplete or suboptimal functionality.
  • Modern features which include graceful fallbacks for browsers which do not support the feature (ie Backdrop video vs static poster image) may be seen as a bug by the client, prompting a discussion about why a feature was handled in such a manner.

Let's go over some talking points we use when discussing browser support use in client meetings, and then outline some base browser support tiers.

Determining Browser Support

How can we determine what browsers a project should support?

At Fuse, we start with a baseline of support which we feel covers most projects. It doesn't have to fit every project, and probably won't, but having a starting point saves us from recreating browser support tables every time and can be tailored to suit the project specifications.

Some things to keep in mind when discussing browser support with a client:

  • Not all clients understand what browser support is.
  • Some clients may have varying expectations of which browsers, versions, and platforms the project should support.
  • A client may not understand the implications of modifying browser support tiers after development has begun.

Important factors in determining browser support include the following:

Analytics data

When available, be sure to review the analytics data for the client's existing project. As browser usage varies between industries, companies, and individual websites, getting the most accurate data possible about the client's specific project is critical to making informed decisions about browser support.

For example, if less than 1% of the visitors of a current site use an obsolete browser, is it really worth the client's money to support it? Similarly, if the analytics shows that a large percentage users are using an older browser, how should an important modern feature in the project specification be handled?

Project features

Complex or modern features are often difficult and sometimes impossible to implement in some browsers.

What features are present in the project specification? How critical are these features and how many of them are there? Are fallbacks or enhancement features for a technology available and/or appropriate?


If there are not enough resources (time, money, developers) to support a feature set on an older browser then priorities may have to be adjusted based on the project's feature requirements and tempered by realistic application of available analytics data. Inversely, a project with a larger budget will have more room to improve support on older browsers, but may still have to compete with other development requirements for additional resources.

Client Request

Should a client request an outdated or obsolete browser be supported, we should determine why they find support for that browser to be important. Sometimes it is simply that they want to have their site be usable by as many users as possible, but do not understand the amount of resources required to support it.

This is an opportunity to discuss the budget implications and the facts about their users. If the client would still like to support an older or unsupported browser, then we can make modifications to the base browser support tiers (and budget), discussed in the next section.

Browser Support Tiers

Determining a base browser support system allows for a solid starting point during browser support discussions with a client. This base level of support should be used as an outline and can then modified if necessary for each project. This system was inspired by BBC's Browser Support Standards, but modified in order to be a more flexible starting point for use on a per-project basis.

The four support tiers are outlined below. All browsers should be categorized into one tier.


The page should appear and function as outlined in the design documentation, mockups, prototypes, etc.

With some reservations, the page should fully work in this browser. All content is readable, interactive elements work as outlined in the project specification, visual flourishes appear as intended, and so on.

As there are always browser inconsistencies, and because it is possible that specific issues cause problems with one or more features of the site, it is not possible to guarantee a 100% identical experience across all browsers. However, affected browsers in this tier will include a workaround, fallback, or alternative to alleviate issues as much as possible.

Limited Support

The browser is able to render the page in a reasonable manner, but will not likely be able to include all features.

Where necessary, fallbacks are used in place of incompatible effects, cosmetic flourishes, and other elements and effects not critical to the consumption of the page content by the end user. Fallbacks and alterations may range from exactly matching the behaviour of a supported browser to being completely omitted, and depends largely on the feature in question.


This browser is unable to render the page due to one or more technical limitations.

Efforts will be made to provide a visitor using this browser to view content in a reasonable, basic format. Any enhancements past a basic presentation of the content requires a separate audit and estimate.


This browser is not considered at any point during the course of the project.

An obsolete browser is not supported in any capacity. Clients wishing to support an obsolete browser to any degree must inform the developer before project work begins.

Closing Thoughts

It is important to have a game plan for browser support when starting a new project. Clearing up any misconceptions on the subject early on helps to avoid any potential misunderstandings during the development process. The suggestions above are not a hard and fast rule, and should be adjusted to fit your team and client projects.