Skip to navigation

The browser supremacy

Awareness of the implications and constraints of different technologies – specifically browser and platform compatibility issues – is an essential component of any developer’s skillset; but in our quest to support as many browsers as we can, it’s often prudent to draw a line. This naturally means reducing support for some older legacy browsers that have non-standard or only partial CSS support and/or a minority user base.

Like most digital agencies, we (Cimex) have developed a baseline browser guide, which identifies a list of browsers that we routinely develop for. In these browsers, we guarantee that our sites will maintain a consistent look and feel and, in some cases, take advantage of advanced features to enhance the user-experience. In other browsing devices, functionality will ‘degrade gracefully’ ensuring access to a site’s services are not exclusive. If you’re interested, the current list is as follows:

This list was compiled by looking at browser usage statistics, making reasonable assumptions about technologies and using our common sense (always a danger).

It’s important to note that our browser list is far from set in stone and we often need to deviate from it on a per-project basis. So, how do we deal with clients who request support for browsers that do not fall within our guidelines? I could just say ‘with great difficulty’, and I’d be right, but that wouldn’t make much of an article, now…would it?

Our first step is to determine why this support is required. In some cases, the client may have evidence to support the fact that a significant proportion of the user-base are using a ‘legacy’ browser. For example, several of our government clients were until very recently still using IE 5.0. In a similar vein, we have also worked on sites that have a predominately third-world user base and are using relatively outdated technology. Once we’ve established the facts, we review the findings and if there is sufficient evidence that a browser makes up a reasonable number of the visitor base, we will support it, no question.

Of course, this is not always the case and on several occasions we have found no genuine business case for including them. Dealing with these issues at an early stage is essential as their inclusion is likely to have a major impact on the methods we use to develop the site, which, in turn, could affect design decisions and also add unnecessary time to development.

The primary issue with supporting older browsers is that we are often forced to create non-standard mark-up to cater for browser specific flaws. This is something we need to consider carefully as we attempt to find a balance between supporting a browser whilst not reducing maintainability or more crucially, future compatibility. Design decisions may be affected and with this in mind, it’s vital that we consider the specific nuances of each browser. Of course, it’s impossible to foresee all problems, but we can definitely set ourselves in good stead.

Additionally and in an ironic twist of fortune, certain flaws in some browsers (mainly flavours of Internet Explorer) allow us to place browser specific rules into separate CSS files. This gives us the perfect platform to support particular browsers, whilst also ensuring future compatibility with newer versions of the software. The actual methods of achieving this are beyond the scope of this article, but you may like to read conditional comments and CSS filters if you are new to this concept.

The nature of what we do commands flexibility in our development practices, and we should be able to adapt to every project we undertake. We should be open minded, focused on our goals and never say no to a browser, unless there is a very good reason to do so. Hail the browser supremacy.

Love what we’ve said? Think we’re talking nonsense? Don’t worry about being polite, just let us have it. We’re not afraid of telling you that you’re talking crap, so don’t be afraid of telling us the same.