Netscape Communications Corporation's Navigator is easily the most loved-and most hated-browser on the Web. By most estimates, at least 75 percent of Web users use Netscape, and some estimates put that figure as high as 90 percent. One reason that Netscape is so popular is that the company has introduced non-standard tags that enhance the appearance of a site. The good news is that most of these tags work-they really do make a site look nicer. The bad news? You have to have Netscape (or one of the few Netscape-compatible browsers) to see the enhancements.
While the Net community debates the relative merits of the browsers, and has agreed to disagree about whether sites that make explicit use of Netscape extensions should be developed, one fact seems clear: No serious Webmaster can be without Netscape Navigator. If he has decided to use Netscape extensions, Navigator is needed to test the pages. If the Webmaster wants to develop pages that don't rely on Netscape, he will still need to see what the client sees when the client says, "I want my page to look just like…."
If you want to start a flame war, just go to any Net discussion group that talks about Web site development and say either, "Netscape Navigator is the greatest thing that ever happened to the Web," or "Netscape Navigator is the worst thing that ever happened to the Web." Either comment will polarize the group-plenty of folks will agree with either comment, and about the same number will object vehemently. While in other groups you'll get some private e-mail that says, "We've already had this discussion, and have agreed to disagree. Please see the archives for details."
Developers who cherish the open standards process by which HTML was developed are concerned that the introduction of Netscape-specific extensions to HTML will confuse and distort the market. Browser vendors who "play by the rules" and concentrate on standard HTML tags lose out when the marketplace demands the Netscape enhancements.
To its credit, Netscape Communications has stated publicly that it supports open standards. It participates in the standards discussions, and has proposed each of its extensions to the standards working groups for adoption. Indeed, many such tags have found their way into the HTML 3.0 standard in some form.
The debate on whether Netscape is the greatest browser ever, or a threat to the free world, will not be settled here. Instead, this chapter deals with the reality of Netscape and the demand for enhanced pages, and describes a process by which your pages can look good with most popular browsers.
David Ornstein, developer of BrowserCaps, sums it up this way:
BrowserCaps (http://www.objarts.com/bc/) is the definitive online source for information about the capabilities of each Web browser.
Table 3.1 contains a summary of the capabilities of Netscape 2.0,
given by BrowserCaps in February 1996. Check BrowserCaps from
time to time to see how the capabilities of the various browsers
have changed.
| Note |
In BrowserCaps and many other parts of the Web, the Netscape browser is known as Mozilla. It's a long story… |
| BrowserCaps Test | |
| Anchors | |
| Link titles (title attribute in <A>) | |
| Mailto address, as a hyperlink | |
| Specification of author's e-mail address
(<LINK REV=MadeHREF="mailto:…">) | |
| Character Formatting | |
| Big text (<BIG>) | |
| Font color for all body text (text attribute in <BODY>) | |
| Font color for arbitrary text (color attribute in <FONT>) | |
| Font sizing (size attribute in <FONT>) | |
| Small (<SMALL>) | |
| Subscript (<SUB>) | |
| Superscript (<SUP>) | |
| Dynamic Content | |
| Marquee (<MARQUEE>) | |
| Entities | |
| Accented entities | |
| Headings | |
| Heading levels (1 through 6) | |
| Images and Figures | |
| Alternative image text (<IMG ALT=...>) | |
| Figures (<FIG>) | |
| Image spacing (<IMG HSPACE>) | |
| Image transparency | |
| Inline JPEG images in <IMG> | |
| Multiple resolution image fade-in (<IMG LOWSRC="...">) | |
| No border on linked images (<IMG BORDER=0>) | |
| Right-aligned images (<IMG ALIGN=Right>) | |
| Scaling images (<IMG WIDTH=... HEIGHT=...>) | |
| Lists | |
| Custom bullets for list entities (<LI SRC="...">) | |
| Definition lists (<DL> tag) | |
| List headers (<LH>) | |
| Nested definition lists (<DL>) | |
| Ordered (numbered) lists (<OL>) | |
| Paragraphs in list items (<P> in <LI>) | |
| Sequence numbers in lists (<OL SEQNUM>) | |
| The <DIR> list element | |
| Paragraph Formatting | |
| Center-aligned paragraph (<CENTER>) | |
| Paragraph center alignment (<P ALIGN=Center>) | |
| Paragraph justification (<P ALIGN=Justify>) | |
| Paragraph left alignment (<P ALIGN=Left>) | |
| Paragraph right alignment (<P ALIGN=Right>) | |
| Preformatted text (<PRE>) | |
| Return to default alignment (<P ALIGN>) | |
| Parsing | |
| Basic comment | |
| Entities in ALT attribute (<IMG ALT>) | |
| HTML comments containing markup | |
| Right angle bracket in ALT attribute (<IMG ALT=>) | |
| Tables | |
| Anchor targets in tables (<A NAME> in <TABLE>) | |
| Basic table (<TABLE>) | |
| Headings in tables (<H3> in <TABLE>) | |
| Post-break in table cell (<BR> in <TABLE>) | |
| Post-para in table cell (<P> in <TABLE>) | |
| Pre-break in table cell (<BR> in <TABLE>) | |
| Pre-para in table cell (<P> in <TABLE>) | |
| Table inside a table (<TABLE>) | |
| Table with an image in one cell (<IMG> in <TD>) | |
| Whitespace | |
| Multiple breaks (<BR>) | |
| Multiple non-breaking spaces ( ) | |
| Non-breaking space ( ) | |
| Whole document | |
| Background color (<BODY BGCOLOR="...">) | |
| Background patterns (GIFs) | |
| Background patterns (JPEGs) | |
| Frames (multiple documents) support | |
| Server Push (multipart/x-mixed-replace) | |
The following is a description of each of these tests:
Recall that BrowserWatch, at http://www.browserwatch.com/, maintains statistics on the relative popularity of each browser. In 1994, the leading browser was Mosaic. In 1995, Netscape took that title. It's entirely possible that Netscape could be dethroned within the next year by a new contender. Check BrowserWatch regularly and follow the discussions in the HTML Writers Guild mailing lists or comp.infosystems.www.* to see what browsers and features are being widely accepted.
The previous information about Netscape reveals a pattern. Many tags or attributes recognized by Netscape are already a stable part of the HTML 3.0 "standard" and can be used freely. There are other elements that are part of the standard, but have not yet been widely adopted. These elements, of course, should be avoided.
Still other features can be implemented in either a Netscape-specific fashion or an HTML 3.0-compliant fashion. In general, the HTML 3.0 style should be favored. Netscape Communications has said that it will fully support HTML 3.0 when it stabilizes, so HTML 3.0 elements will work in Netscape as well as all other HTML 3.0-compliant browsers.
Finally, there are some attributes that are specific to Netscape.
You should avoid many of these. If a site seems to require Netscape-specific
functionality, use the techniques from this chapter or Chapter 7,
"Extending HTML's Capabilities with CGI," to deliver
Netscape-specific code only to Netscape browsers.
| Note |
The following discussion is adapted from Mike Meyer's original paper on Netscape's extensions to HTML, available at http://www.phone.net:80/home/mwm/netscape/. |
The following elements are supported by Netscape and the HTML 3.0 draft, and may be freely used in accordance with the HTML 3.0 draft:
The following capabilities are supported by both Netscape and the HTML 3.0 draft, but have different elements or interpretations of values. Web developers should avoid these elements wherever possible. Since Netscape eventually will support the HTML 3.0 standards, the Netscape interpretation of the following elements is likely to change:
HTML 3.0 tables have a strange "halfway" existence in Netscape. An early version of the HTML 3.0 draft specification was circulated on March 28, 1995, and the complete draft spec was released on July 7, 1995. Netscape began its implementation of tables based partly on the earlier spec, leaving inconsistencies between Netscape's interpretation of tables and the later HTML 3.0 version. For example, the original Netscape tables did not support an ALIGN attribute, and alignment defaulted to flush left (as opposed to center).
The tables in Netscape 2.0 are more compliant with the HTML 3.0 standard, while retaining backwards-compatibility with the Netscape 1.1 version. New pages should be written using only the common portions of the standard. For example, under HTML 3.0, the BORDER attribute has the following legal values:
Under Netscape 1.1, BORDER=n was allowed, where n was the number of pixels of thickness of the border. This style still is allowed in Netscape 2.0, and the HTML 3.0 standard is not supported.
Similarly, HTML 3.0 specifically requires that the caption element of a table be text. Netscape 2.0 allows any BODY element, including headers.
The December 21, 1995 version of the HTML 3.0 table standard is given in "The HTML3 Table Model" at http://www.w3.org/pub/WWW/TR/WD -tables/. The Netscape version is at http://home.mcom.com/assist/net_sites/tables.html and covers both Netscape 1.1 and Netscape 2.0.
As HTML 3.0 stabilizes, Netscape is likely to accept more and more HTML 3.0 equivalents. Each of the following Netscape elements has an HTML 3.0 equivalent:
Be careful with the <CENTER> tag. If you must use it, always think about how the page looks if a browser ignores the <CENTER> tag. Consider, for example, how the following code displays in a browser that does not recognize <CENTER>:
God is <CENTER>now</CENTER>here!
Perhaps the author's intention is better expressed with the following:
God is <CENTER> <BR> now <BR> </CENTER> here!
The following Netscape extensions have no HTML 3.0 counterpart. However, their use does not usually cause a problem in non-Netscape browsers, and is not likely to cause information loss.
The following Netscape tags have no HTML 3.0 counterpart. Be careful not to rely upon them to emphasize text, since visitors not using Netscape (including robots and spiders) cannot see the emphasis. Continue to use headers, <EM>, and <STRONG> to add emphasis.
Here is a process to produce a site that can be validated at several levels, and that looks as good as the browser allows:
In the rare cases where a page must be so heavily enhanced for Netscape that it becomes unusable by any other browser, consider building a separate Netscape-specific version of the page. One method of serving up Netscape-specific pages (use of the <META> tag with HTTP-EQUIV=REFRESH) is given in Chapter 1, "How to Make a Good Site Look Great." Other methods of delivering the correct page to the client based on the client's browser are described in Chapter 7, "Extending HTML's Capabilities with CGI."
In general, there are five classes of browsers accessing the Web:
As a rule, the Web site developer should develop for the largest possible market, while taking advantage of as many features of the high-end browsers (including Netscape and compatibles) as possible. Consider implementing limited workarounds for the more popular broken browsers, and continue to encourage vendors supplying those browsers to fix or replace their products.
Many developers have opted to ignore the 10 to 25 percent of the market who, for one reason or another, do not use Netscape. While that is the developers' right, it seems unwise to deliberately snub a large percentage of your prospective customers. Some sites go to great lengths to tell the user which browser to use, how to configure it, and even what kind of video card to use. Since it's relatively easy to build a site that takes advantage of many Netscape features without sacrificing quality when viewed with a non-Netscape browser, notices such as "Best viewed with Netscape" can legitimately be interpreted as a sign of laziness or incompetence.
In the near future, it is likely that browsers and servers will use a new technique called content-negotiation to decide how to display different types of Web data. When that day comes, sites that are already friendly to many different kinds of browsers will not need to change their appearance to the user. Pages that have advertised themselves as "best viewed with [a certain browser]" will have to change that message, and also change how they serve the data.
In late 1995, Netscape began circulating beta versions of Netscape 2.0, and the product was released in February 1996. Netscape 2.0 offers two major new features, as well as numerous extensions and refinements. The major changes include JavaScript (discussed in the next section) and frames (discussed in this section). Other additions include client-side image maps and file upload.
Frames allow the page developer to put multiple documents on one screen. The screen can be split vertically, horizontally, or both ways. A given frame can have scroll bars and can allow or prohibit resizing.
Frames can be used to make a page absolutely hideous. The FRAME spec allows the developer to specify the size of the frame in pixels or in percentage of screen space. Anything specified in pixels has the potential of overflowing the screen. Even if the user has a large monitor, there's no guarantee that the user is looking at the site in a maximized window.
Frames also can make a page look too busy. Some sites put up three or four frames, with something different going on in each one. While this might seem useful to the developer (who is, after all, familiar with the site), dealing with so many frames can be quite confusing to a visitor.
A better use of frames is to keep a directory or table of contents in front of the visitor in one small frame, and present the content in another frame. Netscape itself offers an excellent example of this design at http://home.netscape.com/eng/mozilla/Gold/handbook/javascript/index.html shown here as Figure 3.1.
Figure 3.1: Some of the most attractive example of frames come from Netscape itself.
More sophisticated examples appear at http://home.mcom.com/comprod/products/navigator/version_2.0/frames/exec_recruit/index.html and http://home.mcom.com/comprod/products/navigator/version_2.0/frames/eye/index.html.
When using frames, it's a good idea to specify TARGET=_top on all outbound links. This addition keeps the screen from splintering when pages with frames link to other pages with frames. Notice the difference between linking without TARGET=_top (see Fig. 3.2) and with (see Fig. 3.3).
Figure 3.2: Without Target=_top, the destination only fills the current frame.
Figure 3.3: When Target=_top, is specified, the destination replaces existing frames.
Netscape has anticipated the fact that many users are not able to see frames. They support a <NOFRAMES> tag; everything between <NOFRAMES> and </NOFRAMES> is sent to any client that cannot read frames. If a Web developer elects to use frames, he should supply a <NOFRAMES> equivalent for use by browsers that cannot handle frames. Netscape 2.0 also introduced client-side imagemaps, a development long awaited by many Net programmers.
To understand why client-side imagemaps are so welcome, you need to understand how conventional server-side imagemaps work. A graphic suitable for use as an imagemap is shown in Figure 3.4.
With server-side imagemaps, whenever a user clicks an image that is specified as ISMAP, the browser adds the coordinates of the click to the request sent to the server. The server picks off the coordinates and compares them to various hot spots defined in the map file. If the coordinates fall within one of the hot spots, the server returns the file associated with that hot spot.
All this computing and comparing is rather CPU-intensive. While any CPU can keep up with a few users, some servers with many imagemaps really suffer from the load. Furthermore, users often notice the delay, and sometimes opt to bypass the imagemap and go to text-based links.
With a client-side imagemap, the image and map are sent to the browser. The browser interprets the click locally and requests the appropriate file from the server. The whole process is much faster, and significantly decreases the load on the server and network as a whole.
Here is an example of a typical client-side imagemap:
<MAP NAME=myMap> <AREA SHAPE=rect COORDS="10, 20, 30, 40" HREF="/some/url"> ...more <AREA...> tags </MAP> Here's how to hook it in: <IMG SRC="some.gif" USEMAP="#myMap"> To be sure your map won't fail on a non-Netscape browser, consider formatting the <IMG> tag like this: <A HREF="/server/imagemap.cgi"> <IMG SRC="some.gif" ISMAP USEMAP="#myMap"> </A>
If the browser understands USEMAP, it ignores ISMAP. If it doesn't understand USEMAP, the server-side imagemap program gets the click.
Prior to Netscape 2.0, forms were capable of handling text in various types of fields and simple selections like check boxes, radio buttons, and pop-up menus. With version 2.0, Netscape has added a new attribute, ENCTYPE, to the FORM; this attribute allows forms to read file data. Consider the following example:
<FORM ENCTYPE="multipart/form-data" ACTION="/some/URL" METHOD=POST> Send file named: <INPUT TYPE=file NAME=userfile> <INPUT TYPE=submit VALUE="Send File"> </FORM>
The URL named in the ACTION attribute of the form should be a CGI script that's prepared to deal with the file on STDIN. It can do anything with the file that any CGI script can do on that server (save it to disk, parse it, send it somewhere else, and so on).
A third major extension to Netscape in version 2.0 is JavaScript. Whereas HTML is a markup language intended to describe the structure of a document, JavaScript is a programming language intended to do work.
Web developers are currently exploring the uses of JavaScript. Two classes of applications already have been identified.
Prior to the introduction of JavaScript, a Web developer who wanted to put up a form needed to write a program-or use a program that someone else had written-to take apart the form, check that it was filled out completely and properly, and then put the contents of the form to work (in a database, for instance, or e-mailed to the developer).
Programs to process data coming from a Web site use the Common Gateway Interface (CGI) and are known as CGI scripts. (Chapter 7, "Extending HTML's Capabilities with CGI," describes CGI authoring in more detail.) To validate a form using a CGI script, the browser sends the contents of the completed form to the server, where the CGI script runs. If there's a problem, the CGI script must send a new page back to the browser. The user reads the message, then goes back and tries again.
Each attempt at filling out the form requires the browser to send the complete form back to the server. All this sending back and forth and processing on the server increases load on the server and network, and slows down response to the user.
With JavaScript, the form itself does much of the validation. The user's own computer can check to make sure that certain fields are not left blank, or that certain values are consistent. Only after the form has been validated by the local script are the contents sent to the server.
JavaScript has almost unlimited ability to enliven a site with simple animation, moving text, and interactivity. The developer can put scrolling messages in the status window, specialized calculators on the page, and flashing, spinning, and whirling graphics all over the place.
Just because you can do something doesn't mean that you should do it. Like almost every feature of the Web, some developers are taking this feature to the extreme, producing the digital equivalent of flashing neon signs.
Continue to use the principles of building a site for a specific purpose. Define goals and objectives. Test for effectiveness before fielding the site or any major changes, and measure effectiveness throughout the site's life. In most cases, you'll find that it takes only a little "sizzle" to sell fine steak.
This section describes how to build a JavaScript script to do simple validation on a form.
The form in this case allows visitors to the Bob's Homes site to add themselves to a mailing list. The form asks each user for name, address, phone number(s), and e-mail address, and makes sure that these items are all filled in. The form also allows the user to enter optional comments in a TEXTAREA.
Listing 3.1 shows the code that implements the form.
Listing 3.1 List31.htm-Embedding JavaScript in the
File Allows the Form to Validate Itself Before Going to the Server
<HTML>
<HEAD>
<TITLE>Join our mailing list!</TITLE>
<LINK REV=MADE HREF="mailto:morganm@dse.com">
<SCRIPT LANGUAGE="JavaScript">
<!-- Hide script from browsers that don't know about SCRIPTs
function validate(form)
{
// require everything except the last three items
// (text area and two buttons) to be filled in
for (var i=0; i<form.length - 3; i++)
{
if (form.elements[i].name.substring(0,9) == "required-" &&
form.elements[i].value == "")
{
var theName = form.elements[i].name.substring(9,
form.elements[i].name.length)
alert("Please fill in your " + theName + ".")
return false
}
}
form.submit()
return true
}
// End the hidden script -->
</SCRIPT>
</HEAD>
<BODY>
<H1>Join our mailing list!</H1>
<P>
Please fill out the form below to join our mailing list.
<FORM METHOD=POST ACTION="http://www.dse.com/cgi-bin/dse/formmail.pl"
onSubmit="return validate(this)">
<TABLE>
<TR>
<TH ALIGN=Left>Name</TH>
<TD><INPUT TYPE=Text NAME=required-name></TD>
</TR>
<TR>
<TH ALIGN=Left>Address</TH>
<TD><INPUT TYPE=Text NAME=required-address></TD>
</TR>
<TR>
<TH ALIGN=Left>City</TH>
<TD><INPUT TYPE=Text NAME=required-city></TD>
</TR>
<TR><TH ALIGN=Left>State</TH>
<TD><INPUT TYPE=Text NAME=required-state></TD>
</TR>
<TR>
<TH ALIGN=Left>Zip</TH>
<TD><INPUT TYPE=Text NAME=required-zip></TD>
<TR>
<TH ALIGN=Left>Day Phone</TH>
<TD><INPUT TYPE=Text NAME=required-dayphone></TD>
</TR>
<TR>
<TH ALIGN=Left>Evening Phone</TH>
<TD><INPUT TYPE=Text NAME=required-nitephone></TD>
</TR>
<TR>
<TH ALIGN=Left>E-mail</TH>
<TD><INPUT TYPE=Text NAME=required-email></TD>
</TR>
</TABLE>
<TEXTAREA NAME=comments ROWS=10 COLS=40>
Please enter any comments here.
</TEXTAREA>
<BR>
<INPUT TYPE=Submit VALUE=Send>
<INPUT TYPE=Reset VALUE=Clear>
</FORM>
</BODY>
</HTML>
| Tip |
JavaScript scripts always start with a <SCRIPT> tag. It's a good idea to put all JavaScript functions in the header. That way, all of them are downloaded before the user has a chance to call them. |
The script itself is wrapped inside a comment. This style is not elegant, but is the recommended approach, and is necessary to keep the script from being displayed by browsers that do not recognize the <SCRIPT> tag.
The next 19 lines of the script implement a function named validate. The argument of the function is a form. The first statement looks like a conventional for statement in C or C++. It says to start the variable i at 0, and increment it each time through the loop as long as i is less than the number of elements on the form minus three. By examining the form, you see that there are 11 elements: eight text fields, the TEXTAREA, and two buttons. So form.length-3 is 11-3, or 8. We need to search only the first eight elements to see if the field has been filled in.
Next, validate examines each of the first eight elements on the form and pulls out the first ten characters of the name of the element. If that substring matches the string "required-" then the script continues processing this element; otherwise, it skips to the next element.
In this way, we can set an element to be required just by putting "required-" at the front of its name, without changing any of the script.
If the name begins with "required-", the script checks to see if the value is empty. If it is, the script strips off the "required-" and puts the rest of the name into the variable theName. The script then presents an alert to the user: Please fill in your …, filling in the stripped field name as part of the alert.
If all required fields have been filled in, validate returns True.
When a user activates the Submit button, the form calls its [onSubmit] method, which in this case tells it to use the value returned from calling validate on this form. If the form is properly filled out, validate returns True, permitting the form to invoke its action (in this case, a call to the CGI script formmail.pl on the server). That CGI script (not the local JavaScript) returns the next page, which replaces the form. (See the section entitled "How to Write a CGI Script" in Chapter 7, "Extending HTML's Capabilities with CGI.")
There are several important differences between Java and JavaScript. Java is a lightweight, object-oriented language developed by Sun Microsystems. It is a compiled language-the developer uses the Java Software Development Kit to produce a binary file that runs on a virtual machine. Netscape (and others) have licensed Java-Netscape implements Java's virtual machine in Netscape 2.0. When a script uses the <EMBED> tag to load and run a Java applet, the applet runs on the virtual machine, which in turn runs on the local platform.
JavaScript is a simplified version of Java. Some of the more sophisticated (and therefore more complex) object-oriented features of Java have been left out of JavaScript.
As a safeguard, there's no provision in Java or JavaScript to write to the local disk. In theory, there's no way to propagate a virus through Java or JavaScript (though there have been several discussions about this issue on the Net).
Java is well within reach of any programmer who is comfortable with C++. JavaScript is much easier to learn, and is within reach of the class of programmers who write Visual Basic programs and Perl scripts.
Chapter 7 discusses scripts that use CGI. Until JavaScript is widely adopted, CGI will be the only choice for many online topics. Even with JavaScript, there are many functions that require access to the server. Storing data in a database, or looking it up, should be done on the server. Sending the contents of a form by e-mail requires access to the server.
Until everyone has JavaScript, scripts should either be restricted to pages that are accessible only to the Netscape 2.0 browser, or scripts should be written so that not running the script has no ill effect.
For example, consider what happens to the form validation script discussed above if the browser is unaware of scripts. Following the Internet Robustness Principle ("Be liberal about what you accept, and conservative about what you produce"), browsers ignore tags and attributes they don't understand, so the browser ignores the <SCRIPT> and </SCRIPT> tags, along with the onClick attribute of the Submit button. It also ignores the script itself, since it's inside a comment.
The script-challenged browser, then, sees a form with a conventional Submit button, a POST method, and an ACTION that invokes a cgi-bin on the server. The server validates the form's fields, and reports any errors (since the local JavaScript has never run).
As an added bit of sophistication, the local script could set a hidden field named, let's say, Validated. A cooperating CGI script could then look at that field. If the field were set to Yes, the CGI script could bypass certain checks; otherwise, it would know that the JavaScript had not run, and could perform the checks itself. In this way, the page would take advantage of JavaScript when it's available, but still would work correctly when run from the most unsophisticated browser.
Microsoft's entry into the browser world is intended to be a Netscape workalike. With a few minor exceptions, such as the MARQUEE tag, its extensions duplicate Netscape's extensions. When Microsoft's browser announces its name, it gives "Mozilla," the Netscape name. This enables the CGI scripts, which give one page for Netscape and another for other browsers, to give Microsoft Internet Explorer (MSIE) the same page they give Netscape.
In the short term, Netscape still has a huge market share compared to Microsoft. In the long term, it's tough to bet against Microsoft. As far as the Webmaster is concerned, all of the comments about Netscape enhancements apply to MSIE, so once a Webmaster has developed a plan on how to deal with that browser, the plan will also cover MSIE.
Netscape Communications Corporation's Navigator may be the best thing that ever happened to the Web, or it may be the worst. What is certain is that experienced Webmasters are seldom neutral on the subject. This chapter described why Netscape Navigator is so controversial, and spelled out a process by which most of the enhancements in Netscape can be duplicated using more standard code. It also showed which Netscape enhancements can be safely used, and which enhancements to avoid. Finally, this chapter described some specific enhancements from Netscape Navigator 2.0, and showed how to take advantage of frames, file uploads, and JavaScript.