A few years ago, Netscape had over 90% of the browser market to itself. Now it’s a minority browser… shows how fast things can change on the Web. So anybody who develops a site that works fine on today’s majority browser has to expect that, some time down the road, that browser will also be in the minority, and something else may have come along. So, developers with a longer view don’t just try to make their site work well on one browser; they try to use robust development that will work on other browsers as well. But not all of them understand exactly what this entails, and they get surprised the first time somebody tells them that their site fails miserably in a different browser.

These days, it’s usually a Netscape user who complains that a site doesn’t work, because the developer never saw fit to test the site on that browser. In some of these cases, the cause is a bug in Netscape. Netscape 4.x is full of bugs, especially concerning the handling of Cascading Style Sheets and international character sets. The newer Netscape 6.x and 7.x have a new set of bugs. So you can’t rule out a site failure being the fault of Netscape if it works in other browsers.

But this isn’t always the case. It is also true that Netscape is stricter in requiring standards compliance on the part of site developers in several areas, and as a result, some cases where a site works in other browsers but not in Netscape are the fault of the site creator or server maintainer — the fact that the site “works” in another browser is simply the result of that other browser applying error-correction processing (sometimes in a “Do-What-We-Think-You-Mean” attitude that actually violates the standards itself). The use of a validator can catch many of these problems. Here are a few specific instances:

Missing Closing Tags

Netscape is very unforgiving about missing ending tags for some elements, particularly TABLE and FRAMESET. A page can show up completely blank if one is missing.

Incorrect MIME Types

The HTTP standards say that the server must identify the data type of all documents through a “Content-Type” (MIME type) header, and that the browser is supposed to accept this as accurate and not second-guess it. Netscape follows this standard; MSIE doesn’t. Microsoft follows its usual attitude of thinking it knows better what the user really wants, and as a result, it sometimes “corrects” the MIME type to something it thinks is more logical. This can cause some sites to “work” in MSIE and not in Netscape, if embedded content (e.g., Shockwave animations) is sent with an improper MIME type (such as a server default of “text/plain”, meaning plain text, which many servers will use if not specifically configured with something else).

Netscape follows the standards and tries to display this content as plain text, while MSIE “fixes” it by analyzing the data and deciding that it’s really an animation. On the other hand, sometimes this second-guessing gets MSIE in trouble; I’ve created scripts that generate plain-text output, properly MIME-typed as text/plain, which worked fine in Netscape but caused MSIE to go into conniptions trying to deal with the data as anything but plain text. Try this test script to see what your browser does.

At any rate, if somebody points out that your snazzy multimedia content doesn’t work in Netscape, check that your server is sending the proper content types for them.

Nonstandard Elements

Perhaps the reason why your site “doesn’t work” in Netscape is that you’re using nonstandard proprietary extensions added by Microsoft. If your site relies on such tags as MARQUEE or BGSOUND, you’re out of luck, because these have never been part of the HTML standards, and are not supported by Netscape.

Form Elements Not In A Form

It is not valid in HTML to include such form elements as INPUT and TEXTAREA anywhere that is not within a FORM element. Netscape won’t display such elements at all if they’re not properly nested within a form, while some other browsers do. It really makes no logical sense to have a form element that isn’t in a form, but some Web authors do anyway, for instance in creating navigational controls that use JavaScript, or in presenting scrolling text via a textarea element. These things aren’t really a good idea, as they make your site dependent on scripting languages, etc., impairing accessibility. But if you must do them, at least include a FORM element around them to make the syntax legal and stop Netscape from ignoring them.

Bad URLs

Another cause of broken images and bad links is the use of invalid URLs. MSIE does some error correction to URLs that Netscape does not, making some improper things seem to work. In particular, paths in URLs are supposed to be delimited with forward slashes, not backslashes, but MSIE tolerates backslashes. Also, various characters such as spaces and some punctuation marks are illegal in URLs unless escaped as hexadecimal numbers preceded by a percent sign (%20 for a space, for instance), but MSIE will automatically encode these improper characters before sending the URL to the server, while Netscape won’t, and this causes some failures at the Netscape end as the server doesn’t know how to deal with those characters in their raw form.

The best way to deal with this is not to give your files names that include spaces or punctuation other than the dot between the filename and extension (even though some of today’s operating systems seem to encourage it); that way you won’t end up with funny characters in your URLs. If you must use such characters, be sure to encode them properly. And don’t forget that directories are delimited with forward slashes.

Popularity: 1% [?]