Netscape Gecko Compatibility Handbook

• 発行日 2002-08-16

Contents

• Introduction
• Verifying Compatibility With Netscape Gecko Browsers (AOL for Mac OSX, CompuServe 7, Netscape 6/7 etc.)
• Evaluating Your Site
• Testing From Within a Firewall
• Preparing Customer Support Information
• Quick Reference: Web Site Problems/Solutions
• In-depth: Problems Due to Existing Coding Techniques
  • Using browser-specific proprietary HTML markup (such as LAYERS)
  • Using browser detection or sniffing
  • Coding workarounds for well known bugs
  • Using obsolete APIs or Web Authoring tools
• Inappropriate DOCTYPE specifications
• Problems related to plugins
• Problems due to web servers
  • Incorrectly specified MIME types
  • Faulty implementations of HTTP
  • Faulty implementations of SSL
• Diagnostic Tools
• Problem Reporting
• References

Introduction

The goal of this handbook is to help you create and update websites that work with standards-based browsers and properly detect Netscape Gecko. Netscape Gecko is the name of the browser engine embedded in Netscape 6 and 7 (in beta), Mozilla, AOL for Mac OS X, CompuServe 7, a Windows version of AOL (in beta), as well as other browsers. The Netscape DevEdge site has resources to help you learn more about compatibility with methods prescribed by the World Wide Web Consortium.

Why the need for a handbook? Here's a little background. Since 1997, much of the Web's content has been developed for Microsoft Internet Explorer 4 or Netscape Navigator 4. These browsers were developed before the relevant W3 Standards for HTML, CSS and the DOM were created.

On the other hand, Netscape Gecko was designed from the ground up to support W3 Standards rather than the proprietary approaches of the past. The ultimate goal of standards is to simplify web development in the long run. However in the short term, the result is that pages coded using non-standard, proprietary techniques may not display as intended in Netscape Gecko-based browsers.

Key differences between earlier, non-standards based browsers and Netscape Gecko inclunde:

1. These browsers use proprietary (non-standard) HTML, CSS and JavaScript.
2. Internet Explorer 4 and Netscape Navigator 4 share support for a large part of the HTML 3.2 standard and basic JavaScript.
3. While they support the CSS 1 standard to some degree, the implementations are not complete and are non-standard.
4. Neither Internet Explorer 4 or Netscape Navigator 4 support the W3 DOM. Instead, each browser supports its own proprietary API for manipulating the content, style and position of HTML Elements in a web page.
5. In addition, Internet Explorer 4 and Netscape Navigator 4 use completely different methods of embedding. third-party software into the browser.

As discussed in Mozilla.org's Using Web Standards in Your Web Pages, cross-browser coding for cross-browser compatibility requires you write standard markup that Netscape Gecko-based browsers, Netscape 4, and IE browsers can render properly.

Testing Your Site with Netscape Gecko Browsers (AOL for Mac OSX, CompuServe 7, Netscape 6/7 etc.)

Netscape Gecko is a cross-platform browser engine, compatible with a number of Windows versions including Windows XP, as well as Mac and Linux. Because of Netscape Gecko's cross-platform nature, functionality is generally very much the same on different platforms unlike IE for Mac and IE for Windows, which are very different programs and so may behave quite differently from each other.

Mozilla.org's Using Web Standards in Your Web Pages is a great introduction to tags and techiques supported by Gecko-based browsers.

However, even if your site works on Netscape 6, it's important to test your site in AOL for Mac OS X and CompuServe 7. Due to possible browser detection and network issues, you'll want to verify that all areas of your site load and function correctly.

Visit Netscape Gecko Central for additional information and links. Webmaster@AOL has further information regarding compatibility with AOL's service.

Evaluating Your Site

Want to see right away how your site works with Gecko-based browsers? If you're using user-agent detection, try the User-Agent Toolbar:

1. Launch Netscape 7 or Mozilla 1.0 for OSX (The benefit of using Mozilla is that if you're only detecting "Netscape" or "Netscape6" you'll see the issues right away.)
2. Go to the ua bar site and click "Install xpi here"
3. After re-starting your browser, select the AOL for Mac OS X ua string from the toolbar dropdown list.
4. Hit Enter -> click Shift-Reload to reload the page. You can verify the string got changed by looking under Help | About.

Then test using the ua string for CompuServe 7: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.2) Gecko/20020502 CS 2000 7.0/7.0. But as mentioned previously, it's best if you can download the actual client for testing.

We also strongly recommend you do not detect these entire strings but instead use more efficient methods to lower your maintenance, as newer versions may be launched with changes in the date, for example. [Related article]

Reviewing Your Results

a) Site look funny? If your site is already Netscape 6 compatible, then try switching back to a Netscape 6 ua string. If it looks ok, you're probably detecting only "Netscape" or "Netscape6." Detecting "Gecko" instead is the easy way to fix this. [Related article]

NOTE: Detecting "Gecko" will also "fix" your site for users of Mozilla, CompuServe 7, etc.

b) Still look funny? Try picking the IE 6 string. If this works, set up your detection to serve IE 6 content to visitors with "Gecko" in their ua strings.

c) Give up? Please take a look at the troubleshooting section of this handbook.

If you need to connect to AOL via a corporate firewall, America Online has registered TCP/IP ports 5190 and 11523 so you can communicate with the AOL client software. This way you can test your site on the AOL client from behind your firewall, provided that your network administrators will open these ports.

You need to be connected to the Internet to test your site on AOL; it isn't possible to access your site on a local machine via your LAN, without an Internet connection.

If your site lists system requirements or caveats, because your visitors will not know what "Netscape Gecko" is, we recommend that you use specific browser names as needed:

• AOL for Mac OS X
• CompuServe 7
• Netscape 6+
• Mozilla

Quick Reference: Web Site Problems/Solutions

In-depth: Problems Due to Existing Coding Techniques

In this section we detail the most common causes of the problems affecting standards-based browsers and how to avoid them.

1. Using Browser-Specific Proprietary HTML Markup (such as LAYERS).

   Since a browser is supposed to ignore HTML tags it does not recognize and render the content inside the tags, Web page authors have used the technique of combining proprietary HTML that will work as expected in each browser.

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

   The prime example of this is the use of Netscape Navigator 4 proprietary LAYER, commonly used in site navigation. For standards-based alternatives, see Updating DHTML Web Pages for Next Generation Browsers .

   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 Gecko browsers, 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

   While browser detection is useful in enabling authors to code pages that work only in specific browsers, improper browser detection can lead to major user experience breakages. [ related article]

   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.

   Alternatively, web page authors can 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 Gecko as if it is Netscape Navigator 4 .

      The following example uses the navigator object and its 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 Gecko 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 Gecko. The CSS that is appropriate for the buggy implementation of CSS in Navigator 4 is not appropriate for the standards-compliant Netscape Gecko . 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 Gecko 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 Gecko browsers. Therefore, pages that use the is_nav4up will inappropriately treat Netscape Gecko 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. This is unfortunately not the case.

   2. The page does not recognize Netscape Gecko 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 Gecko browsers where neither proprietary API is implemented.

   3. The page may recognize Netscape Gecko but not recognize other browsers based upon Netscape Gecko.

      <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 article for a better approach to detecting browsers.

3. Depending on bugs and browser-specific quirks

   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 Gecko browsers since it implements the standards strictly. The old "code to the bugs" approach will not work for Netscape 6 and 7 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 - and 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

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

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

   should be line-through
   should be underline

   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 web developers have for learning about the standards.

   Due to the common nature of this error, Netscape 6.2 began 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 Gecko 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 began 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 Gecko browsers 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 (such as image maps)

   Many authors seem to be infected by a 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 Gecko 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 do support Netscape Gecko however. For example, DYNAPI is now maintained at SourceForge and offers a Netscape Gecko-compatible version. Newer versions of web authoring tools such as Adobe GoLive 6 support Netscape Gecko. The following software updates are also available:

   • Dreamweaver 4 update
   • Adobe GoLive 5.0 update

Problems due to inappropriate DOCTYPE specifications

Standards related to CSS and Layout pose a problem for web page authors wanting to support older browsers such as Internet Explorer 4 and Netscape Navigator 4. These browsers do not implement W3 Standards correctly, unlike newer browsers such as Netscape 7. How is a Web page author to write web pages so that the page will display as intended in all of these browsers?

Netscape Gecko, Internet Explorer for Mac OS 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. [ related article ]

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 and 7 if an inappropriate Layout mode is specified.

Netscape Gecko 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.

Netscape Gecko 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 Related to Plugins

You'll find for that some plugins behave differently in Netscape Gecko than in Netscape Navigator 4. Visit DevEdge Plugins Developer Central to learn about the features leading plugin vendors support in Netscape Gecko browsers, changes in the plugin architecture vs. the Netscape 4 generation, and suggested plugin strategies.

Plugins that are now scriptable with Netscape Gecko browsers, so your players can "talk" to web pages, inclunde: Apple QuickTime 6, Macromedia Flash 6 r47, RealPlayer 8 and RealOne.

Problems due to Web Servers

• Incorrectly specified MIME types

  Many Web servers have incorrectly specified MIME types for files. Of particular interest to Netscape Gecko browsers are the following:

  • HTML - text/html
  • CSS - text/css [ related article ]
  • XML - text/xml

• Faulty implementations of HTTP

  Several Web Servers incorrectly implement the HTTP protocol which can result in problems for Netscape 6.

• Faulty implementations of SSL

  Older browser such as Internet Explorer 4 and Netscape Navigator 4 implemented older versions of the Secure Sockets Layer (SSL) protocol. The most common version of SSL on the web today is SSL 3.0, however the newest version TLS ( SSL 3.1 ), which is supported by Netscape Gecko browsers is not supported by many Web Servers today. Unfortunately, several implementations of SSL 3.0 incorrectly implement the negotiation of which version of SSL to use and fail to connect to Netscape Gecko browsers.

  For more detail on this issue, please read Notes on TLS/SSL 3.0 Intolerant Servers .

Useful Resources

• See DevEdge for a complete list of articles, tools, and other resources.
• Beginning to intermediate Web Authors can look to the DevEdge Web Tune Up Wizard for pointers on areas where content needs to be updated to support Netscape Gecko and other browsers that support the W3C standards.
• AOL Webmaster.info Site - Developing for Netscape Gecko covers common issues facing webmasters, and how to update your code.

Diagnostic Tools

The W3C provides several tools that are invaluable when diagnosing web page problems:

• W3C HTML Validator: The W3C HTML Validator will validate any Web page according to the W3C HTML standards. It is very useful in detecting the use of proprietary HTML as well as in detecting invalid HTML.
• W3C CSS Validator: The W3C CSS Validator will validate the CSS contained in any Web page or external CSS files according to the W3C CSS standards. It is very useful in detecting invalid CSS.
• HTML Tidy: HTML Tidy is a tool that can be used to report on errors in an HTML page and can be used to format web pages for better reading.
• Mozilla.org JavaScript Debugger: Mozilla.org is working on a powerful JavaScript debugging environment for Netscape Gecko-based browsers, including the Netscape 7.x series of browsers.

• 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.

Problem Reporting

• Mozilla/Netscape browser or web site problem reporting
• DevEdge Community

References

• AOLWebmaster.info Site: AOL compatibility information
• DevEdge Web Tune-up Wizard
• Using Web Standards in Your Web Pages
• Browser Detection and Cross Browser Support
• Updating DHTML Web Pages
• HTMLElement Cross Reference
• Client Object Cross Reference
• Introduction to Cross-Browser JavaScript and Dynamic HTML

• DevEdge 日本
• DevEdge 英語版
• フィードバック

• テーマ/スキン
  • Gecko ブルー
  • 描かれた砂漠
  • DevEdge クラッシク
  • 霧中