My Site Doesn't Work In
[<== Previous] | [Up] | [Next ==>]
TIP: If your site works fine in one browser but fails
miserably in another, it might be a bug in the second browser,
but it might be your own bad development that's at fault --
maybe the second browser is actually following the standards
correctly instead of second-guessing them!
A few years Over a decade ago [time flies!], Netscape had over 90% of the browser market to itself.
A few years later, it was a minority browser... and now it's pretty much vanished entirely. This 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.
For a while in the aftermath of the first round of browser wars, it was usually a Netscape user who complained that a site
didn't work, because the developer never saw fit to test the site on
that browser. This is basically a thing of the past now, in the specific case of Netscape quirks, given the
vanishing of this browser, but the principle is one that still needs to be considered since similar
issues show up for each of the browsers in use now. As I wrote this page originally in an earlier era, it describes
some issues specific to a long-dead browser; it should be regarded as historical in nature. However, the general
concepts are still relevant, and some of the specific points even still apply to some current browsers.
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
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.
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
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
TEXTAREA anywhere that is not within a
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
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
around them to make the syntax legal and stop Netscape from ignoring them.
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
If you use an external stylesheet or script, be sure it actually
exists and you used the correct URL for it (and see the above section
about URL validity). That's even worse than a broken image; if there's
a missing stylesheet or script, Netscape will replace the entire page
with the "404 Not Found" error page supplied by the server when the
missing element was requested. You might not notice this on other
browsers because they simply don't use the stylesheet or run the script,
but otherwise display the page correctly; Netscape users, on the other
hand, can't see your page at all unless they change their browser
Incorrect Stylesheet Syntax
While Netscape 4.x certainly has its share of bugs in interpreting
Cascading Style Sheets, and hence a stylesheet failure in Netscape
might easily be Netscape's fault, this isn't always the case. In some
cases, Netscape actually follows the standards better. A case in point
is that the standards call for a browser to ignore a stylesheet altogether
if its syntax is incorrect, rather than try to muddle through it and
possibly screw things up badly. Netscape does this, so if you find that
your stylesheet has no effect at all, maybe it's because your syntax
is wrong. Some other browsers just barrel ahead doing what they think
you really meant, and you may never find out you're using bad syntax.
Try the W3C CSS Validator
to check your stylesheets (both external and inline within HTML).
One example of this is the use of measurements with no unit, like
width:600. This is invalid; numbers are supposed to be followed
by a unit such as "px" for pixels or "pt" for points. They're meaningless
without one. Coders who rely on the sloppiness of some browsers which
infer "pixels" for unitless numbers often create stylesheets which fail even
in the new, standards-compliant Mozilla browser, as well as the old Netscape
4.x. But they still try to blame the problem on Netscape. In fact, this
"no units" problem seems to be a perennial one on the newsgroups which draws
whiny comments like "Well, it works in MSIE, so that means Netscape
is broken!", as well as protests about the wastefulness of having to add two
extra bytes to each style item to "get around this Netscape bug" (this usually
from developers who have added many more bytes to their pages with
their sloppy coding -- like the use of separate inline style elements all over
the place where a single external stylesheet with well-defined classes would work
This is a fairly common one on the "WayKewl" pages that insert today's date
"marketing types" keep insisting on doing in the delusional belief that this
will somehow make their sites seem up-to-the-minute). If the date shows up
in Netscape as "August 5, 101", it means that they're using the
method. In Netscape, this returns the year minus 1900, so in 2001 it will
result in 101. In MSIE, it returned a two-digit year prior to 2000, but
returns a four-digit year from 2000 on. Thus, the date looks correct in
MSIE but not in Netscape.
So which is correct? The ECMAScript
Language Specification says that
getYear() is supposed to
return the year minus 1900, so by this standard Netscape is correct. The
standard, however, also says that this is an obsolete function, and should
be replaced with
getFullYear(), which always returns a four
digit year (well, until the year 10,000, anyway...) Or, if you're worried
about support for really ancient browser versions that didn't support this
function, you need to put the output of
getYear() through some
conditional logic to add 1900 to it if it's less than 1900, and leave it
alone otherwise (which will work correctly until the year 3800).
To get really technical, what Netscape is claiming to support is not "ECMAScript"
named to resemble Java (even though it's not a version of Java, or
even very much like Java, even if its syntax has some slight resemblance).
guilty. So you can't necessarily say that either of them is "violating the
standards", since they're using scripting languages that don't formally
have standards. (But if you regard the language as proprietary,
then Netscape's implementation should be considered the normative one since
the ECMA people have made the noble effort
to turn this proprietary language into something that is standardized in a
non-vendor-specific way, and this is worthy of support. And by this standard,
Netscape's implementation of the date functions is correct, and MSIE's is wrong.
Prior to 2000, both implementations used a two digit year for
and many scripts just stuck "19" before it; hence, you ended up with abominations
like "19100" (in Netscape) and "192000" (in MSIE) on pages using this function
in such a simpleminded way, and these turned out to be practically the only
easily noticeable manifestations of the over-hyped "Y2K Bug".
This is specifically a Netscape 6 (or Mozilla) "problem". Support
for character set standards has greatly improved in this version, which
might be troublesome for site developers who aren't following them.
One thing I've noticed, for instance, is that sites where the server is
configured to send a "charset=us-ascii" parameter in the MIME type for the
HTML pages, but still try to display 8-bit characters like foreign accented
letters (which aren't part of the US-ASCII character set), don't work. All
8-bit coded characters (everything above #127) show as question marks --
depending on your font, either a plain question mark or a pretty neat looking
inverse-video question mark within a diamond shape. This is a perfectly
reasonable thing for the browser to do, since it's being asked to display
characters that are undefined. (Entity names and numeric references with
ampersands work fine, as they should.) However, since it doesn't match the
bogus "do-what-I-really-mean" behavior of earlier Netscape browsers or of
MSIE, many developers never notice that they're doing the wrong thing with
Along with the question marks in place of foreign letters, you may also
sometimes notice question marks in place of quotes, apostrophes, and dashes.
In that case, it means that the page developer used characters that are
nonstandard even if the "proper" character set parameter was used. These are
the 8-bit characters in the Windows character set for such things as curly
quotes, which are vendor-specific and not part of a character encoding
standard. You should avoid these, and use either the standard ASCII straight
quotes or the high-number Unicode numeric references for the curly characters.
See more discussion of character set issues in my page
on characters and fonts.
Here are a few more things that aren't technically invalid, necessarily,
but can also pose problems for Netscape, and are not a good idea to do
for this and other reasons.
Netscape didn't support BMP (bitmap) graphics, at least prior to
the Mozilla-based versions 6 and up. (This was added
to the Mozilla project in 2001.) While it's not
technically nonstandard to use BMP images on the Web (if your server sends
the proper MIME type for them), it's not a good idea; other than the
non-MSIE and non-Windows compatibility problems, they're not a good format for
Web graphics in general. BMP files aren't compressed, so their size
is much bigger than a compressed format such as GIF, JPEG or PNG.
This wastes bandwidth, transmission time, and disk space both on your
server and the users' browser caches. Change to a compressed format,
and your site will be better for everybody.
Microsoft-Specific Scripts and Applications
If your site uses VBScript or ActiveX, those are Microsoft-specific
proprietary vendor applications, and you shouldn't expect them to
work in any other browser. And you should also know that these Microsoft
scripting languages have shown themselves to be much more vulnerable
to viruses, trojan-horses, and other security risks than their
If you find that some things you intended to be centered don't work
out that way in Netscape, it may be because you used a
element to enclose things which Netscape doesn't consider to be validly
part of a paragraph. Under the standards, when something that can't
properly be nested within a paragraph is encountered, this implicitly
closes the paragraph, even without a
tag, so that anything that follows is not within the paragraph (and hence
not centered). Neither of the popular browser makers follows the
standards correctly and completely in this regard; they each have their
own interpretation of what belongs in a paragraph and what doesn't,
not entirely matching what the standards say. In particular, Netscape
doesn't let you put form buttons within paragraphs (though as far as I
can see in the standards, they ought to be usable this way). Here, I
think it's Netscape that's wrong, not the web author, but you can still
avoid the problem by using
<DIV ALIGN="center"> instead of
Odd-Sized Form Fields
Netscape does funny things with form fields if you try to set the fonts
in them away from the normal default. In particular, if you use a non-fixed-width
font, the fields are sized based on the widest character in the font, not the average
character, so that the fields are wider than you expect. If you set a smaller font
size, that will make the fields narrower, but also make the input text be in a teensy,
hard to read font. So don't put
<FONT> tags around input fields,
or try to use stylesheets to set input fonts to anything but a fixed-space font.
Overuse of font specifications is a bad idea, anyway, as it limits the ability of
the page to adapt to differing systems and user preferences.
As you have seen, the blame for your site not working in Netscape
might sometimes point squarely at you. Check your code and your server
configuration, and fix it!
[<== Previous] | [Up] | [Next ==>]
This page was first created 29 Apr 2001, and was last modified 26 Sep 2010.
Copyright © 1997-2011 by Daniel R. Tobias. All rights reserved.