Netscape DevEdge

Skip to: [content] [navigation]

This resource is obsolete and is provided for reference purposes only.Please see for the latest information.

Diagnosing Web Pages for Netscape 6/Mozilla Support

How to spot and diagnose (most) common web page problems for Netscape 6/Mozilla

Contents



Introduction

To understand the types of problems you may have when browsing the web using Netscape 6, you must understand a little of how Web page authors and designers have developed content since 1997.

Most content today has been developed for Internet Explorer 4 or Netscape Navigator 4. These browsers were developed before the relevant W3 Standards for HTML, CSS and the DOM were created and use proprietary (non-standard) HTML, CSS and JavaScript. Internet Explorer 4 and Netscape Navigator 4 share support for a large part of the HTML 3.2 standard and basic JavaScript. They also support to some degree the CSS 1 standard although the implementations are not complete and are non-standard to say the least. Neither Internet Explorer 4 or Netscape Navigator 4 support the W3 DOM. Instead, each browser supports it's own proprietary API for manipulating the content, style and position of HTML Elements in a web page. In addition, Internet Explorer 4 and Netscape Navigator 4 use completely different methods of embedding third party software into the browser.

Netscape 6, on the other hand, has been designed from the ground up to support the W3 Standards and not to support the proprietary approaches of the past. This can cause pages that were coded using non-standard, proprietary techniques to not display as intended in Netscape 6.

Problems due to Existing Cross Browser Techniques

In order to support Internet Explorer 4 and Netscape Navigator 4, web page authors have used a variety of techniques.

  1. Using Browser Specific Proprietary HTML Markup.

    Since a browser is supposed to ignore HTML tags which it does not recognize and render the content inside the tags, Web page authors have used the technique of using combinations of proprietary HTML that will work as expected in each browser. The prime example of this is the use of Netscape Navigator 4 proprietary LAYER tags in combination with tags that are supported by Internet Explorer.

    Since Netscape 6 will ignore both Internet Explorer and Netscape Navigator 4 proprietary HTML tags, a page may not display in Netscape 6 as it does in Internet Explorer 4 or Netscape Navigator 4.

    An HTML page can be quickly checked for the use of proprietary HTML Markup by submitting the page to the W3's HTML Validator using the HTML 4.01 DOCTYPE. We will have more to say about DOCTYPEs later in this article, but essentially the DOCTYPE is supposed to indicate to a browser what version of HTML is used in the page.

    The HTML Element Cross Reference provides a list of all HTML Elements supported in Netscape 4, Netscape 6, Internet Explorer 4 and up and can be used to determine which HTML Elements are supported by all browsers.

  2. Using Browser Detection or Sniffing

    Web pages that use JavaScript can detect which browser is being used to view them either by looking at the navigator object or by detecting proprietary features in a browser's JavaScript implementation.

    By detecting which browser is being used to view a web page, authors have coded pages which use Internet Explorer 4 only techniques when viewed with Internet Explorer and which use Netscape Navigator 4 only techniques when viewed with Netscape Navigator 4.

    Web page authors also dynamically write browser specific HTML depending upon the browser being used to view the web page. This is done both in the web page itself using the JavaScript document.write function and on the Web server to output browser specific HTML and JavaScript.

    Three problems can occur when a web page uses browser detection to determine which proprietary features to use for a particular browser:

    1. The page mistakenly identifies Netscape 6 as if it is Netscape Navigator 4.

      The following example uses the navigator object and it's properties to detect which browser is viewing the page.

      <script language="JavaScript">
if (navigator.appName == "Netscape")
  document.write('<link rel="stylesheet" type="text/css" href="nn4.css"');
else if (navigator.appName == "Microsoft Internet Explorer") 
  document.write('<link rel="stylesheet" type="text/css" href="ie4.css"');

if (navigator.appName == "Netscape")
  obj = document.layers['id'];
else if (navigaor.appName == navigator.appName == "Microsoft Internet Explorer") 
  obj = document.all['id'];

</script>

      Note how the above code does not distinguish between Netscape 6 and Netscape Navigator 4. This results in two problems in the above conde:

      1) The JavaScript will present a Netscape Navigator 4 specific CSS Style sheet to Netscape 6. The CSS that is appropriate for the buggy implementation of CSS in Navigator 4 is not appropriate for the standards compliant Netscape 6. Symptoms of this problem are improper appearance of a Web page.

      2) The JavaScript will attempt to use the document.layers object which will result in an error since Netscape Navigator 4 supports the proprietary document.layer object while Netscape 6 does not. Symptoms of this problem are JavaScript errors for document.layers, document.layername, x and y properties of Image objects not being defined, etc.

      A related problem is due to the use of Ultimate Browser Sniffer.

      <script language="JavaScript" src="ultimate-sniffer.js"></script>
<script language="JavaScript">

if (is_nav4up)
  document.write('<link rel="stylesheet" type="text/css" href="netscape.css"');
else if (is_ie4up) 
  document.write('<link rel="stylesheet" type="text/css" href="ie.css"');

</script>

      The problem with the Ultimate Browser sniffer is_nav4up variable is that it will be true for both Netscape Navigator 4 and Netscape 6. Therefore, pages that use the is_nav4up will inappropriately treat Netscape 6 as though it were Netscape Navigator 4. Unfortunately, Web Developers were encouraged to code using the is_nav4up and is_ie4up variables, since the belief at the time was that any later version of Netscape would be compatible with Netscape Navigator 4.

    2. The page does not recognize Netscape 6 at all. 
      <script language="JavaScript">

if (document.layers)
  document.write('<link rel="stylesheet" type="text/css" href="netscape.css"');
else if (document.all) 
  document.write('<link rel="stylesheet" type="text/css" href="ie.css"');

</script>

      Note how the above checks for Netscape Navigator 4 (document.layers) and Internet Explorer 4 and above (document.all) but completely misses Netscape 6 where neither proprietary API is implemented.

    3. The page may recognize Netscape 6 but not recognize other browsers based upon the Mozilla Open Source browser. 
      <script language="JavaScript">

var ua = navigator.userAgent.toLowerCase();
if (ua.indexOf('netscape6') != -1)
  document.write('<link rel="stylesheet" type="text/css" href="netscape.css"');
else if (document.all) 
  document.write('<link rel="stylesheet" type="text/css" href="ie.css"');

</script>

    Please see the Browser Detection and Cross Browser Support for a better approach to detecting browsers.

  3. Depending on bugs

    Since a Web page is judged not by how well it is written but by how well it displays in a browser, authors have developed many techniques which take advantage of idiosyncracies in particular browsers to achieve the desired effect. This is of particular importance since the early implementations of CSS found in Internet Explorer 4 and Netscape Navigator 4 had many bugs. In order to achieve the desired effects on a page, authors wrote HTML and JavaScript which depended upon these bugs in order to work properly.

    This can cause problems in Netscape 6 since it implements the standards strictly. The old "code to the bugs" approach will not work for Netscape 6 and other Mozilla based browsers.

    Example - Putting forms in Tables

    INVALID HTML to eliminate line break in FORM

    In older browsers, this results in the TD cell tightly wrapping around the input element.

    <table border="1">
<tr>
<form name="form2">
<td>
<input type="text">
</td>
</form>
</tr>
<table>

    This approach is commonly used to get around the fact that FORM is a block level element in HTML and will naturally begin on a new line in the page. Unfortunately, this is INVALID HTML and can cause problems both when parsing the page and when applying the CSS styles.

    Incorrect Use of XML Empty Tag notation

    Many people have taken to using XML Empty tag notation ( <tag /> ) in their HTML files. In XML, an Empty tag NEVER has any content. The XHTML backward compatibility guidelines state that Empty Elements can be coded by following the tag name with a space followed with as slash as in <tag />. To be backwardly compatible you must have a space before the trailing />. In addition, you must only use the XML Empty tag notation for HTML Elements that are always Empty not for HTML Elements that have optional ending Tags.

    For example, it is ok to code <br> as <br /> although there is no benefit to do so in HTML documents. But it is NOT ok to code <OPTION> as <OPTION />. To understand why, consider the following:

    HTML without optional ending tags Equivalent HTML with optional ending tags
    <select>
    <option>OptionValue
    </select>
    		 <select>
    <option>OptionValue</option>
    </select>

    Now consider if we used the XML Empty tag notation: the <OPTION />

    HTML with XML Empty Tag notation Equivalent HTML with ending tags
    <select>
    <option />OptionValue
    </select>
    		 <select>
    <option></option>OptionValue
    </select>

    This is simply not correct. If you must use the XML Empty tag notation, then only do so for HTML Elements that NEVER have any content NOT for HTML Elements that have optional ending tags.

    CSS ID's should be case-sensitive

    <style type="text/css">
#id1 { text-decoration: line-through; }
#ID1 { text-decorarion: underline; }
</style>
<div id="id1">
should be line-through
</div>
<div id="ID1">
should be underline
</div>
    should be line-through
    should be underline

    Netscape 6 implements the case sensitivity of Class ID's correctly and will display this example correctly while Internet Explorer treats all CSS ID's as case-insensitive and will not display this example correctly.

    Note that the W3C's HTML Validator will flag HTML ID attributes as duplicates if they only differ due to case. There appears to be some inconsistency between the actual HTML 4.01 Recommendation and the SGML declaration for HTML on whether ID attributes are case sensitive or not. This is unfortunate since the HTML Validator is one of the primary vehicles we have for educating web developers about the standards.

    Due to the common nature of this error by web authors, Netscape 6.2 has begun treating CSS ID attributes as case-insensitive in Quirks mode only. If you are invoking Standards mode, you should still code your CSS to be consistent with respect to case. Please note that this document uses Quirks mode.

    CSS Class names should be case-sensitive

    <style type="text/css">
.class1 { font-size: 1em; }
.CLASS1 { font-size: 2em; }
</style>
<div>
<div class="class1">
should be font-size: 1em;
</div>
<div class="CLASS1">
should be font-size: 2em;
</div>
    should be font-size: 1em;
    should be font-size: 2em;

    Netscape 6 implements the case sensitivity of Class names correctly and will display this example correctly while Internet Explorer treats all CSS Classnames's as case-insensitive and will not display this example correctly.

    Due to the common nature of this error by web authors, Netscape 6.2 has begun treating CSS Class attributes as case-insensitive in Quirks mode only. If you are invoking Standards mode, you should still code your CSS to be consistent with respect to case. Please note that this document uses Quirks mode.

    Incorrect Relative URLs

    A Relative URL is one which refers to the same web server where a web page is hosted. A Relative URL that refers to a path relative to the directory where a Web page is located looks like path/file.html. Relative URLs that refer to a path relative to the web server's root directory look like /path/file.html.

    Older browsers supported the INVALID use of http://path/ for URLs relative to a web server's root directory but Netscape 6 and Mozilla do not. To correctly specify a web page relative to a web server's root directory, use URLs of the form /path/file.html.

    Invalid use of spaces in name Attributes

    Many authors seem to be infected by the penchant to use spaces in names. A name or id attribute in HTML 4.01 may not legally contain spaces. This can cause problems with Gecko based browsers especially in image maps. You should make sure that your name attributes are coded using valid characters only.

  4. Use of Obsolete APIs or Web Authoring tools

    Many older versions of Cross Browser APIs in common use around the web such as DYNAPI do not support Netscape 6 for one or more of the reasons listed above. This is also the case for older versions of Web Authoring tools such as Macromedia's Dreamweaver 2 and 3.

    Newer versions of these APIs and tools exist however that do support Netscape 6. For example, DYNAPI is now maintained at SourceForge where a Netscape 6 compatible version can be found. Also, newer versions of Web Authoring tools such as Macromedia's Dreamweaver 4 support Netscape 6.

Problems due to inappropriate DOCTYPE specifications

Standards pose a problem for Web page authors in how to support the older, legacy browsers such as Internet Explorer 4 and Netscape Navigator 4. The older browsers do not implement the standards related to CSS and Layout correctly according to the W3 Standards, but the newer browsers such as Netscape 6 do implement these standards correctly. How is a Web page author to write web pages so that the page will display as intended for the older browsers while at the same time displaying as intended in the modern standards compliant browsers?

Netscape 6, Internet Explorer for the Macintosh and Internet Explorer 6 all use a technique called DOCTYPE sniffing to determine if a page is to be laid out in a fashion compatible with the older browsers or if it is to be laid out in a fashion compatible with the W3 standards.

Using the appropriate DOCTYPE in an HTML document allows a web page author to continue to support the older, less compliant browsers while also supporting the newer, more compliant browsers by specifiying special Quirks mode layout via the DOCTYPE. As time progresses and the older browsers drop in market share, web page authors can transition to standards based layout by using the appropriate DOCTYPE.

While DOCTYPE sniffing is a useful means of continuing to support the older browsers, it can be a problem for newer browsers such as Netscape 6 if an inappropriate Layout mode is specified.

Mozilla has two layout modes: Quirks and Standard. Quirks mode mimics the behavior of Netscape Navigator 4 while Standards mode follows the W3C Recommendations for HTML and CSS. In particular, Standards Layout Mode uses the CSS Box Model as defined in Chapter 10 of the CSS 2 Recommendation. The mode is picked based on the doctype declaration (or the lack thereof) at the beginning of an HTML document.

Mozilla also has two parsing modes: Quirks and Standard. Quirks mode allows the use of invalid comments containing two dashes -- while Strict modes does not.
<!---- This is an invalid HTML Comment accepted in Quirks Comment Parsing ---->
<!-- This is a valid HTML Comment accepted in Stricts Comment Parsing -->

For the exact rules on which DOCTYPEs invoke Quirks vs Standards mode see Mozilla's DOCTYPE sniffing article.

Problems due to Web Servers

Diagnostic Tools

The W3 provides several tools that are invaluable when diagnosing problems with a web page:

Perl also is a useful tool for diagnosing the response of Web Servers. Perl is a standard language interpreter available for both Unix and Windows platforms. A standard utility called HEAD is available with Perl distributions that can be used to view the HTTP headers sent by a Web Server.

Diagnosing Problems with a Web page
Symptom Possible Problem Solution
Content does not appear the same in Netscape 6 and Internet Explorer Use of Proprietary Markup
Use of Invalid Markup
 Use the W3 HTML and CSS Validator tools to validate the web page. Correct any errors reported by the validators.
Content does not appear the same in Netscape 6 and Internet Explorer Incorrect Browser Sniffing
Use of Proprietary JavaScript

The JavaScript Console in Netscape 6 displays errors about document.all, document.layers, document.<property> not being defined.

 Update Browser sniffing to correctly detect Netscape 6 and other browsers based upon Mozilla.
Upgrade APIs to use newer Standards conformant versions
Upgrade to Web Authoring tool versions that support the W3 Standards and Netscape 6
Content does not appear the same in Netscape 6 and Internet Explorer The Web page author has coded his CSS to use the bugs in Internet Explorer's implementation of CSS.

Internet Explorer incorrectly treats ID's and CLASS names as case insensitive while Netscape 6 treats them correctly as case sensitive. The Web page author has used inconsistent case between the CSS defining the style for HTML ID's and CLASSes which results in Netscape 6 not applying the styles to ID's or CLASS names that differ in case.

Internet Explorer incorrectly specifies height and width of inline elements such as SPAN.

Internet Explorer implements the box model (padding, margins, borders) incorrectly.

 Do not use Internet Explorer's invalid implementation of CSS. Use only the Cross Browser, Standards conformant features of CSS. Use consistent case when writing HTML ID and CLASS name attributes and CSS Styles for those IDs and CLASSes. Do not specify heights or widths on inline elements such as SPANs. Use only Cross Browser box specifications for margins, padding and borders.
Content does not appear the same in Netscape 6 and Internet Explorer Incorrect Layout mode specified by DOCTYPE
 If pages are to be displayed by legacy browsers such as Internet Explorer 4 and 5 or Netscape Navigator 4, be sure to specify Quirks mode layout via the DOCTYPE.
Images are laid out without intervening blank areas in Interent Explorer but display blank areas between the images in Netscape 6. Incorrect Layout mode specified by DOCTYPE Standards Mode Layout has been specified by the DOCTYPE, change the DOCTYPE to request Quirks mode layout instead.
Clicking on a link works in Internet Explorer but results in a 404-Page not found in Netscape 6 The web page author is using an invalid form of a relative URL. Change relative URLS from http://directory/... to directory/.... or use absolute paths in URLS such as http://server/directory/...
Clicking on a link in Internet Explorer displays the referenced content while in Netscape 6 a download dialog is displayed. The Web Server has incorrectly specified the MIME type for the content. Internet Explorer tries to guess the MIME type of documents while Netscape 6 relies upon the Web Server to specify the correct MIME type. Netscape 6 does not try to 'sniff' the MIME type for a document in order to reduce the possibility of unsecure, dangerous content masquerading as as a safe MIME type. Use Perl's HEAD utitility to determine the actual MIME type being used by the Web Server. Correct any incorrect Server MIME types .
Connecting to a secure site works in Internet Explorer but Netscape 6 fails to connect. The Web Server does not properly implement the fall back negotion for SSL. Contact the administrator of the Web Server and convince them to upgrade their SSL software. In order to use a site with a defective implementation of SSL, disable TLS in Netscape 6 until the site has upgraded to software that correctly implements SSL.
Content appears correctly when using Netscape 6 but not Mozilla or other browsers based upon Mozilla The Web page author's Browser detection JavaScript detects Netscape 6 but does not detect Mozilla. Upgrade the browser detection JavaScript to handle Mozilla and other Gecko based browsers.
DHTML Menus implemented using HierMenu do not work or place the popup in the wrong position. The page is using an obsolete version of HierMenu. The earliest version of HierMenu only supported Netscape Navigator 4.x and Internet Explorer 4.x and above. Later versions did support Netscape 6 however changes in Netscape 6's (beginning in 6.1) support for Internet Explorer's proprietary offsetXXX properties resulted in HierMenu placing popups in the wrong position. The most recent versions of HierMenu fully support Netscape 6.0, 6.1 and 6.2 as well as all Gecko based browsers. Upgrade to the most recent version of HierMenu.


References

A–+R