The myth of the supported browser

A common note on web sites is an indication of which browsers you're supposed to use, or what browsers they expect you to use. As an old hand on the Internet, this both confuses and annoys me.

The annoyance is because I'm a bit of a rebel. I don't like being told what clients I may and may not use - and by implication what Operating System I'm expected to use, and hence what hardware I should own!

The confusion is because - well, what other servers do you encounter that do that? How many sites running FTP or SMTP servers and ask that you use a specific client? For that matter, is there any other protocol documented in an RFC where you encounter statements like "Please use client foo", or are told that your client is wrong because it does things according to the RFC instead of the way some - demonstrably broken - implementation does it? Why is HTTP different?*

Investigation quickly reveals that when some web site maintainer says "We only support these clients", what they really mean is "We wrote for these clients". That makes sense, as there are many different clients. There may be as many as a thousand of them, depending on how you count different. Who would want to write for and then test that many clients?

The problem is, that doesn't answer the question. The question was not "Why do sites support only a few browsers", it was "Why are web sites different from FTP and SMTP sites?"

Investigating software for network servers other than web sites, we find that the authors of those systems do not write for a client - they write for a standard. Oddly enough, the authors of the clients also write for a standard. The standard provides a common framework for both groups. The net result is that a network site and a client that properly follow the same standards will work together. Every time. That bears repeating, and loudly:

A network site and a client that properly follow the same standards will work together.

Ok, we now have the answer to the original question: Web sites are different from other network sites because the developers write for a specific browser, and not for a standard. In examining the relevant standards, the reasons are quickly apparent - in some cases, they don't exist, or are written by vendors for users instead of implementors. For those that do exist, the client authors didn't write to them, even though they claim to follow those standards.

The question for web site developers is what can they do to improve things? The answer is actually simple - write for the standards! Any client that fails to follow those standards is buggy, and you may, in good faith, have users of those clients request that the bug be fixed. Then test with a browser that follows the standards. I recommend amaya. Realistically, your site must work with the big two. Since those two have notoriously bad implementations of the standards, testing with them is a requirement. You can then work around their bugs - hopefully while still following the standards! Clients other than those two follow either the standard or those two, so you will be ok in either case.

The sad part of all this is that web site developers don't merely write for a small, specific set of browsers - they write for a set of features that those browsers support! Disabling those features on clients that support them - even the ones the site supports - tends to break those sites. The best sites notice that you've disabled the feature, and use another mechanism. This means those sites work with browsers that don't support that feature. The better sites notice that you've disabled the feature in question, and tell you that you need to enable them. Most sites don't even notice that you've disabled them.

Worse yet, some of these features provide tools for malicious site developers and users access to your browser or computer.

Fortunately, such sites seldom depend on those features, and use them for time-wasting annoyances. So disabling them makes most sites work better: they don't open new windows when you visit them, or have annoying scrollers in the status bar, or crash your browser, or any one of a number of obnoxious behaviors. So I recommend going through your browsers preferences, and turning off as many things as you can. If you don't notice a difference - leave it off. If you do and it's a generally good thing - leave it off, and find sites that don't have problems with it. If you do and things are generally bad - turn it back on.

Do this, and you too can discover that browser support is a myth. What they really support is features - and usually just the buggy implementation of those features by a small set of browsers.


*) I know that HTTP per se has little to do with why web site developers - most of whom wouldn't know an HTTP request if it bit them - do this. It's JavaScript, and HTML, and etc. that are the reasons. But the logic of the paper applies - you just have to use a bigger set of standards.

Mike Meyer
January, 2001