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!
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 elements, particularlyTABLE 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 asMARQUEE 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 asINPUT 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.
Missing Stylesheets or External Javascript
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 settings to disable stylesheets and/or JavaScript.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 much better). Incorrect Use of JavaScript's getYear() Method
This is a fairly common one on the "WayKewl" pages that insert today's date somewhere in the layout via JavaScript code (a stupid and useless thing that "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 thegetYear() 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" but "JavaScript", a proprietary scripting language invented by Netscape and 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). What MSIE claims to support is not "ECMAScript" or "JavaScript", but "JScript", a proprietary knockoff of JavaScript with the name changed to protect the 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 they're the ones who invented JavaScript in the first place.) However, 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
getYear(), 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". Bad Characters
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 characters here.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.
BMP Graphics
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 less-proprietary competitors Java and JavaScript.Centering Problems
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<P ALIGN="center"> 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 </P> closing 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 <CENTER> or <DIV ALIGN="center"> instead of <P ALIGN="center">. 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!
No comments:
Post a Comment