Web Matters

The Netscape 4 conundrum

Note: This article was originally written in the autumn of 2002, when use of Netscape 4 was still quite common in some circles. Even as late as 2005 it would still have been wrong to ignore it completely. However it has now become so uncommon that this article is no longer directly relevant. I leave it here because the general principle behind this page remains valid, and will continue to remain valid as long as the web exists. That is: ensure pages are still readable in older browsers, even if they don't look so good.

The Problem

One of the commonest questions I have encountered in discussions about web authoring is: “What do I do about Netscape 4?” As it took me quite a while to unravel the issues involved, I thought I’d put together a page about the problem, in the hope that it will be of use to others.

Very crudely, one can categorise browsers as follows:

  1. Browsers which support (a subset of) CSS quite well, e.g. Mozilla, Firefox, Netscape 6 and up, Opera 5 and up.
  2. Browsers which have somewhat buggy CSS support: notably Internet Explorer 5 and 6.
  3. Browsers which have dreadfully bug-ridden CSS support. These are most notably Netscape Navigator 4 (NN4) and Internet Explorer 3 (IE3).
  4. Browsers which make no claims to support CSS.

The first and last categories are not a problem. IE 5/6 can be lived with, just about. But NN4 forms a major problem. (IE3 as well, but as it is nowadays very little used, it can probably be safely ignored.) If you doubt this, take a look at the CSS Pointers Group NN4 Bug Page.

If, for example, NN4 would just ignore the “border” property, it would not be a great problem. Pages viewed with it would be a bit less attractive, sometimes a little harder to read, but that’s all. What NN4 typically does, however, is draw a border around an apparently randomly-chosen piece of screen, and not always in the colour you asked for. I have even encountered a case where the element which was to receive the border was transposed to a completely different part of the page! Clearly this is not tolerable.

As a result, it is not uncommon for people to recommend web authors to abandon NN4 support completely, and leaving any remaining NN4 users to struggle. There are however still a large number of readers using NN4. Apparently school/university environments in particular still use it heavily. Recent (2002) estimates I have seen range up to 7% of readers. I do not log browser usage on my own site, but indirect evidence (which I will mention later) suggests that the number of NN4/IE3 visitors to my site is still over 5%. Clearly, for anything other than a hobby page, even 5% is too high to ignore. After all, would you consider a server unavailability of 5% acceptable? (That’s more than 18 days a year).

As to why people continue to use NN4, the main reasons are probably a combination of:

  1. They’ve been bitten by “upgrades” before, and now work on the principle of “if it’s not broken, don’t fix it”.
  2. They don’t have the resources to run NN6 or NN7 (which are notorious resource hogs), don’t trust Internet Explorer (or have a platform unsupported by IE), and aren’t familiar with Opera.
  3. Have a slow, expensive and perhaps not very stable connection, and don’t fancy trying a 10Mb+ download.

If you are interested in further discussion of this, see the alt.html FAQ page: What is the adoption rate of browsers like?

The Solution

But, unlike Will Parker in “Oklahoma!”, it is not a case of “all or nothing”. There are at least four possible approaches:

  1. Get your pages in NN4 looking closely similar to their appearance in more modern browsers, compromising on layout design where necessary;
  2. Get your pages looking roughly similar, but hide incorrectly supported features from NN4;
  3. Hide all presentation from NN4, giving the reader a plain, but perfectly readable, page;
  4. Ignore the existence of NN4 completely.

Approach 1 means limiting CSS usage to what NN4 supports reliably, and using transitional HTML markup for the rest.

Approach 2 can be achieved by using the “@import” feature of CSS, which NN4 ignores (as does IE3). So you can use CSS, but you have to separate it into two files. One, including those properties which NN4 supports, is included via a LINK element. The other, with the features which NN4 does not support properly, is included via @import (just as this page does). You may also need a bit of transitional HTML markup.

With Approach 3, all CSS is included via @import, thus avoiding the need to investigate what NN4 supports and what it doesn’t. This gives the NN4 reader a page with the traditional black text on white background and blue links. The only problem I know of with this approach is that one cannot use inline styles. (I know some people frown on these anyway, but I don’t agree. If one has a style which is specific to one place in the text, why not place it inline?) It may also be necessary to make some use of <HR> elements, where the CSS uses borders, in order to clearly separate different blocks of text.

As for Approach 4: as mentioned above, I do not (yet) think that this acceptable, unless the site is intended for a specific audience where NN4 usage is known to be rare. Given the availability of Approach 3, it probably isn’t necessary either.

I used Approach 1 until the middle of 2002. This does however involve significant limitations, and is probably only justified now if you are working for a client organisation who uses NN4 as its primary browser. (Some universities fell in this category at least as late as March 2003.) As you’ve probably worked out, I have now moved to Approach 2, and will probably stick with it until NN4 usage has dropped to around the 1% mark. Though I might go to Approach 3 if I get fed up of distributing my CSS over two files!

Approach 2 does also give you a method of estimating how necessary the approach is, even if you don’t or can’t log browser usage. You can do this from the ratio of hits on the “@import” css file to the hits on the “link” css file, as NN4 and IE3 don’t generate hits on the former.

Some other issues

There are various other little foibles to be addressed.

  1. NN4 gets confused where to look for image files referenced by a CSS file, if relative references are used. The references are applied relative to the HTML file instead of the CSS file. If you have files at multiple levels in the directory structure, you will need to do whichever is less inconvenient of the following:
    • include copies of the image files at multiple levels as well (but only those referred to by CSS);
    • use absolute references instead of relative references.
  2. Anchors: NN4 only supports anchors defined by means of <A NAME> not those defined by means of the ID attribute. Having to use <A NAME> is a fairly minor irritation.
  3. NN4 does not support transparency in PNG images. Therefore any images with large areas of transparency need to be done as GIFs. For images with small transparent areas, it's a judgement call whether the less attractive appearance to NN4 readers outweighs the benefits of smaller image size for all readers. (Update: I gather that it does support transparency in some circumstances - whether you want to struggle to obtain those circumstances is up to you.)
  4. NN4 has poor support for non-Latin character sets and the larger-numbered character-entity references. In some cases the number reference is supported but the name is not: for example “&#8220;” is supported but “&ldquo;” is not. Work-arounds for some other characters are difficult, but if you use the character names rather than the numbers, it does at least give the reader some chance of working out what is going on. The late Alan Flavell’s character coding checklist may be helpful in addressing this.
  5. Although the end tags for the TD, TH and TR elements are optional, Netscape 4 often has problems displaying the table if they are omitted - so always include them.
  6. Netscape 4 does not support the BUTTON element.

In general it is particularly important to validate pages for the benefit of NN4, as it is less tolerant of erroneous markup than some browsers. But this is hardly a disadvantage - it is after all good practice in any case.

And while you’re at it ...

... do encourage any users of NN4 or IE3 you come across to upgrade their browser. But don’t bully them! As hinted above, while some people may just not have thought about upgrading, others may have reasons for not doing so. Sites which forceably redirect readers to a “you can’t read this site” page on detecting an old browser, surely rank among the lower forms of life which infest the net. (And many of them make it even worse by having incorrect browser detection software.)