browser compatibility – theory and practice

the following entry is a (sanitized and expanded) version of an email i recently sent to a client explaining some of the issues surrounding browser compatibility and web developement. it’s amazing these issues persist after years of slowly grinding towards a world of web standards…someday, i hope these ideas will seem quaint: "oh, how cute! they used to have to worry about those things…"


browser compatibility is a complex issue. it involves balancing the desired user experience with the realities of development timelines (often short), testing facilities (often unavailable). designer desires (usually extravagant) and the wild, wild west of web technology (where there are no rules or standards that anyone has to adhere to).

A definition of browser support
“Browser support” means that a user coming to the site will have the desired experience: the look and feel of the site will be as intended, and all elements of the site will be functional. (See note on expanding the definition of browser support)

It’s important to limit the scope of supported browsers
Why do we limit the scope of browser support? Why not just support everyone and everything? The answer to this question is simple – it’s difficult, time-consuming, expensive and occasionally impossible to support everything (given the definition above) (see note on draconian branch strategies). In some cases, it’s not even possible (for a given browser benchmark) to achieve support for a combination of visual design and functionality. Browsers use technology to render visual and interaction design over the Web, and this technology acts as a constraint on that design, which produces a feedback loop, causing browsers to change design. In addition, in many cases, supporting extended browser compatibility dramatically increases the complexity and scope of a Web site (e.g., different code for different browsers and platforms, etc.).

User experience will vary depending on browser type
There are a few different types of experiences people will have when visiting [insert site here], depending on their browser.

  • Explicitly “allowed” browsers: The site should look, feel, and function as desired. The browsers we currently allow explicitly are:
    • Safari, Internet Explorer 5+, Netscape 6+
    • Firefox, Camino, or any browser based on the Gecko rendering engine
    • Any browser that supports the modern Document Object Model (DOM) [NOTE: in some cases, support for the modern DOM does notabsolutely guarantee a perfect user experience. nonetheless, we elected to try to support all ‘modern’ browsers even though we don’t/can’t explicitly test for all of them]
  • Unsupported browsers: Users are directed to an upgrade page which requires them to upgrade their browser before entering the site. Users with unsupported browsers cannot gain access to the site (see note on draconian branch strategies. At present, we explicitly redirect users with the following browsers:
    • Internet explorer: Versions 3 and 4 (Current version: 6)
    • Netscape navigator: Versions 2, 3, and 4 (Current version: 7.1)
    • AOL: Versions 3, 4, and 5 (Current version: 9)
    • Opera: Versions 2, 3 and 4 (Current version: 7.5)
  • User agents not explicitly excluded or allowed: In many cases, it’s difficult to know exactly what browser (or to be technically correct, user agent) is visiting the site (see note below: User agent identification). In these cases, the user agent is allowed to visit the site. They may or may not have an optimal user experience, depending on the type of agent. For example, Opera 7.5 on the Macintosh is allowed, but it has a bug in the Flash plug-in that causes the home page animation to appear incorrectly.

Defining an acceptable level of support
As described above, a certain fraction of users visiting the site will either be redirected to an upgrade page, or will have a sub-optimal user experience for one reason or another. The most difficult question to answer is, how many visitors fall into this category and what is acceptable??? The technical benchmark stated above was selected to minimize the number of users with unsupported browsers (< 1-2% of site visitors). It's really a business decision as to the order of magnitude of this number. As a side note, establishing a rigid metric (e.g., 1.2%) is dangerous, because statistics regarding the number of users with a given browser should be taken with a grain of salt (see note on user agent identification below).

Can we increase the level of browser compatibility and support?
Yes, but there are cost and development implications. This is ultimately a business decision related to the ROI associated with increasing the level of support. How much do you gain by consuming valuable development resources to support a small fraction of users? Does the importance of those users outweigh the cost?

Can we change the way we deal with unsupported browsers?
Yes. We could alter the way we handle unsupported browsers. For example, we could simply display a message that says “This site optimized for viewing in X, Y and Z browsers.” While this may seem an attractive option, it could have unintended consequences (i.e., a page is broken so badly in a given browser that the user either doesn’t see the message or just decides never to come back to this ‘unprofessional’ web site). We could also redirect to an upgrade page that then provides both links to upgrade and a link that says “Show me the site anyway”, which then allows users into the site with an old or broken browser. In many ways, browser support is a “pick your poison” problem – most solutions have benefits and drawbacks.

A final note about testing
We tested [insert site here] as much as we could, given the twin constraints of time and equipment. Based on my experience, there is a theory and a practice associated with testing. In theory, one establishes a list of things to test, and then tests them. In practice, testing can be very costly, difficult, and time-consuming. In some cases it requires capital expenditures that may not be consistent with project budgets (e.g., to buy equipment, to build a QA lab to perform testing, or to outsource testing to another QA provider). The current [insert site here] was built very rapidly, with very little time (or budget) for testing, and with no universally accessible, dedicated testing equipment. We did not have the machines necessary to test against all possible combinations of supported environments (e.g., no Linux box, no Windows 2000 box). In fact, testing user environments is extremely difficult to do given the "combinatorial explosion" that occurs when trying to test every possible permutation of browser, platform and OS version, installed plug-ins, etc..


I realize this is a long description of what seems like a simple issue. Unfortunately, the Web technology environment is chaotic, and the issue of browser compatibility lives at the heart of this chaos.

best regards,


user agent identification
It is common to write code that examines the “user agent string” for the browser and then tries to determine what the user agent is based on this identifier. Because these identifiers are unregulated, many user agents masquerade as something else (e.g., WebTV “looks like” Netscape navigator to many browser detection scripts). It requires a careful analysis of the user agent string to make an accurate determination. there are literally thousands of user agent strings for hundreds of user agents on the Web. for a sample of what user agent strings look like, look at this list of user agent strings for mozilla, which shows only the user agent strings for “Mozilla” browsers (a terribly misleading umbrella term that subsumes Mozilla, Firebird, Camino, and Firefox, all of which use a similar rendering engine developed as an open-source project by Netscape).

as you can see, the list is ridiculously long. there would be no way to test for all of these combinations, so we wind up looking at these strings for commonalities. in some cases, when looking for a commonality, one can overlook the part of the string that differentiates two user agents. for example, many browser detection scripts misidentify Firefox as Netscape Navigator 6 (which actually identifies itself as Moziila/5.0 – netscape skipped version 5 browsers, for some reason, yet included this in their user agent strings). because Navigator 6 was a browser with severe flaws in its rendering engine, this can often lead to problems…



Expanding the scope of browser support
it is possible to expand the definition of support to include people who can use a site for its intended purpose, while not necessarily seeing it exactly as it was intended. for example, a bug in Flash transparency in OmniWeb on the mac means that the home page looks funny. other than that, the site is perfectly usable and looks as intended. in a worst-case scenario (e.g., Netscape 2 running on Windows 95), the site might look atrocious, but if the navigation is all functional, and the content is readable, this could be considered semantic support.

many companies are loathe to adopt this approach, because it means that people could see a site that’s not an adequate representation of the company brand. it is for this reason that it is sometimes more desirable to adopt what might be perceived as draconian branch strategies (see next note).

draconian branch strategies
some might say you shouldn’t be so draconian, forcing people to an ‘upgrade your browser’ page. some might further argue that every site on the Web should support every user agent, with support defined on a sliding scale. for example, if you’ve got a really old browser, you can still see the content, and ideally you can access all key information, but you may not be able to experience the site as desired by either its parent company or designers.

this is fine – in principle. however, the situation changes when your client’s CEO gets a call from technical support saying, "some high-powered VC using the original beta release of joe’s web browser couldn’t see the home page, and now he’s going to poison our funding well.&quot when said CEO or CTO hears something like this, their immediate reaction is to "fix it." in a heartbeat, the whole sliding-scale approach to briowser support goes out the window. this is just the way it is. in addition, when you’re being told the site has to launch next week, you may not have the time or ability to even guarantee semantic compatibility across the spectrum of browsers and user agents.

another, more subversive, reason lies behind adopting a more draconian branch strategy – getting people to upgrade their browser increases the rate of convergence towards a standards-compliant world. it may seem like an attitude insensitive to those people with older browsers, but:

  • browsers are FREE
  • the only way to get to a world where standards mean anything is to let go of the chaos the past
  • people can hold on to the past and use old technologies, but they have to take responsibility for making this decision. an automotive analogy might help. consider someone who wants to drive a Model T Ford. this is a conscious decision to use an old technology in a world that has clearly moved on. said Model T driver wouldn’t be able to drive on a modern freeway because their car is too slow. do they have a right to ask for a reduction in the speed limit? of course not. no one would consider this reasonable because there are laws set to govern the use of the roads, and the laws (supposedly) favor operational norms in society. there are no such laws on the Internet; there are only standards (which are really unenforceable guidelines).

what about accessibility? this is another large issue that would consume a whole entry in and of itself…of course accessibility is important. a site should (in principle) be capable of being rendered in a text-only browser. the contraints that come into play (again) are the realities of corporate Web development in a world where there is limited time and a limited budget. it really sucks that some people get the short end of the reality stick; i wish it wasn’t this way, but sometimes it is when it comes to building businesses on the Web.

but but but
there are a thousand "but" arguments that you could throw at everything i’ve said. my arguments aren’t all airtight; these are largely my opinions after having spent the last 6 years building Web sites. in fact, i don’t believe there are any airtight arguments about browser compatibility. ultimately, browser compatibility comes down to the reality of what it takes to build a Web site. it’s all theory and practice:

in theory, there’s no difference between theory and practice. in practice, there is.
  – Yogi Berra

that’s what it’s like to build a Web site. everyone wants the theory, but all you’ve got, at the end of the web developer day, is practice.


0 Responses to “browser compatibility – theory and practice”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s



Bits I'm reading


%d bloggers like this: