It's no surprise that with new technology opening up the Web, the multitude of browsers available are starting to show the strain because everyone supports different levels of Web interaction. A vast majority of Web surfers use Netscape Navigator and Internet Explorer but not everyone uses (or chooses) a browser that supports everything. The end result of this explosive growth is the increased load placed on Web designers. The task of creating a site that both takes advantage of new technology and works well for older browsers is becoming increasingly difficult.
Fortunately, there is a collection of scripting tricks that can make your life a bit easier.
Before the days of languages like VBScript and JavaScript, the only way you could steer a surfer to the pages designed for them was:
Present a different link on your home page for each browser type, and let the user select the correct set of pages.
Use a CGI script to identify the user's browser and force-feed the proper pages.
The first technique is still in use today on many sites (see fig. 1.1). Three valuable uses of it are:
This "high-speed/low-speed" option is necessary because there is no way to identify a user's access speed. Even once the world is wired with optical connections, you should still consider offering alternative routes through your site to accommodate "speed surfers" that use text-only browsers or "script surfers" that may be using any one of several different scripting languages.
The downside of using the first technique is that most people are overly curious. Invariably, someone clicks the wrong link and wanders through your site with pages not optimized for his or her browser. He or she perhaps encounters scripting errors or poorly presented pages and draws a negative conclusion about your ability as a Web master. He or she might even e-mail you to complain-yes, such people do exist!
The second technique requires access to the CGI level of your Web server and for you to maintain one page tree (directory) for each supported browser configuration. In essence, you set up your home page as a browser-generic gatekeeper that is accessible even to old browsers. Within the page, any defined links are written to point to a CGI script instead of the HTML file directly:
<A HREF="/cgi-bin/start.cgi">Enter the site</A>
Clicking a link forces the server to launch the CGI script, which then checks the HTTP_USER_AGENT environment variable to determine the browser type. Listing 1.1 shows a Perl fragment that does this.
Listing 1.1 Using CGI to Identify the Browser Type
#!/usr/local/bin/perl
$userAgent = $ENV{'HTTP_USER_AGENT'};
if ($userAgent =~ 'Mosaic') {
}
$htmlFile = 'mosaicVersion.html';
} elseif ($userAgent =~ 'Netscape') {
$htmlFile = 'netscapeVersion.html';
} else {
$htmlFile = 'otherVersion.html';
}
$htmlFile = join ("/", $ENV{'DOCUMENT_ROOT'}, $htmlFile);
print "Content-type: text/html\n\n";
open (HTML, "<", $htmlFile);
while (<HTML>) {
print;
}
close (HTML);
exit (0);
While the script in listing 1.1 is very simple, this method also creates some problems, such as:
Finally, you still have to maintain a separate site for each browser
type you choose to
support. It is a lot of effort for the end result. Fortunately,
the introduction of client-side scripting tools has made this
job easier.
Until the advent of JavaScript and VBScript, the ability to screen users has traditionally been somewhat limited. This generally affected those not running their own Web servers and those who didn't have access to the CGI services of their Web servers. Before discussing the new tricks, let's have a quick review of an old method: client-pull.
Within the browser, the process of loading a new page (or reloading the current page) is initiated by the user through clicking a link or the Reload button. The concept of client-pull was developed by Netscape as an early method of automating this process. In essence, an HTML document contains additional information that instructs the browser to do either one of these:
or
The client (browser) remains in control of the process and, when the specified time has elapsed, "pulls" a new page from the server, hence client-pull. To initiate client-pull, you need to utilize a special HTML tag: <META>.
The <META> (HTML) tag, one of the more esoteric HTML tags, is used within the header block (as defined by the HTML <HEAD>...</HEAD> tag pair) and allows you to embed document "meta-information" that's not defined by other HTML tags. Once in the document, the server can extract or browse for various uses:
Identify a document's content or author
Index and catalog documents on a site
Control the loading or reloading of a page
The third case, client-pull, is of interest in the current discussion because it's the job of the client (browser) to request (pull) the next page based on the information in the tag.
An example <META> tag would be:
<META HTTP-EQUIV="Refresh" CONTENT="secs; URL=newURL">
The two attributes of the <META> tag are:
Listing 1.2 shows a page that directs the user somewhere else; or, if his or her browser supports it, takes him or her there automatically after a one-second delay.
Listing 1.2 Client-Pull
<HTML> <HEAD> <TITLE>Welcome!</TITLE> <META HTTP-EQUIV="Refresh" CONTENT="1; URL=http://www.visi.com/next.html"> </HEAD> <BODY> You really need to <A HREF="http://www.visi.com/next.html">go here</A> </BODY> </HTML>
| TIP |
If you wish to experiment with client-pull and you're using Internet Explorer, you'll need to do your testing online; that is, you'll have to load your pages into your Web site and access them from the server rather than reading them from your local hard disk. While Navigator acknowledges client-pull requests from locally loaded (from disk) documents, Explorer does not. |
For the purposes of browser identification, client-pull does have limitations. Only the oldest browsers don't support it, which are the same ones that don't support much else, leaving you with a collection of browsers that do, which still have varying levels of support for other features. To more accurately identify different browsers and their capabilities, it's necessary to turn to client-side scripting.
Client-side scripting involves one of two languages: VBScript (from Microsoft) or JavaScript (from Netscape). In both, the scripting code is embedded directly into the HTML document, and contained within a <SCRIPT> tag block:
<SCRIPT LANGUAGE="JavaScript"> <!-- hide ... // end hide --> </SCRIPT>
When using VBScript, the LANGUAGE attribute is set to VBScript, but the general configuration of the block is identical.
Any browser that doesn't support scripting ignores the tag but
still displays the script statements as text for display. To hide
the script body from these browsers, wrap the entire body of the
script in an HTML comment statement (<!-- … -->).
| CAUTION |
JavaScript and VBScript handle the comment wrapping in different ways. After JavaScript encounters the first half of the comment tag (<!--), it switches to "JavaScript" mode. From that point on, every line within the script block is assumed to be JavaScript code until the closing </SCRIPT> tag is encountered. This means that the closing comment tag (-->) needs to be prefaced with a JavaScript comment identifier (//) to prevent JavaScript from trying to interpret the tag as JavaScript. VBScript, on the other hand, doesn't make this assumption. In fact, prefacing the closing comment tag with a VBScript comment identifier (') will cause VBScript to generate an error. Therefore, the proper structure of a VBScript block is: <SCRIPT LANGUAGE="VBScript"> <!-- hide ... --> </SCRIPT |
Even though both Navigator and Explorer support JavaScript, Explorer doesn't fully implement the language. Therefore, if you're going to do heavy Java scripting later in your site, you'll want to redirect Explorer users to another set of pages. Trying to get one page set to handle both browsers would require a good deal of conditional scripting. Fortunately, this is done quite easily because both browsers support the JavaScript location object, which permits you to force the loading of a new page. Determine which page to load by examining the navigator object, which stores information about the browser. The conditional loading of different pages for Navigator and Explorer is demonstrated in listing 1.3.
Listing 1.3 Java Scripted Page Selection
<SCRIPT LANGUAGE="JavaScript">
<!--
if(navigator.appName.indexOf("Netscape") != -1) {
location.href = "netscape/index.html";
} else {
location.href = "microsoft/index.html";
}
// -->
</SCRIPT>
At this point, there's only one more case to cover before the client-side gatekeeper is complete: browsers that don't support scripting (such as Mosaic). Because a page containing JavaScript has to be loaded and processed, it's desirable to prevent the no-script version from displaying in Navigator or Explorer. This is accomplished by using a <NOSCRIPT> tag.
With the release of Navigator 3.0, Netscape coined several new HTML tags, including <NOSCRIPT>. The purpose of a <NOSCRIPT> block is similar to that of <NOFRAMES>-it identifies an HTML block for processing by a browser that doesn't support scripting. However, <NOSCRIPT> is not part of the HTML standard and, because of this, many other browsers will probably not adopt it. Explorer doesn't support it, so it's not the best option for specifying scriptless HTML. Fortunately, there is another way that works across all browsers and it relies on a unique attribute of JavaScript.
While the JavaScript interpreter looks inside the comment tag block for its script code, it has the unique function that once it encounters a comment-end (-->) tag, it ignores everything else on that line. Non-JavaScript browsers, on the other hand, pick up the processing after the comment closes and interpret the rest of the line as valid HTML.
This means that you can place an empty comment (<!-- -->) at the beginning of a line inside the <SCRIPT> tag and get an HTML statement that JavaScript (and browser) ignores, but displays to non-scripting browsers. This effectively creates the equivalent of a <NOSCRIPT> … </NOSCRIPT> block, as demonstrated in listing 1.4.
Listing 1.4 Creating a <NOSCRIPT> Block
<SCRIPT LANGUAGE="JavaScript"> <!-- begin hide // JavaScript browsers process this ... // end hide --> </SCRIPT> <SCRIPT LANGUAGE="JavaScript"> <!-- -->Non-Script browsers will process this </SCRIPT>
| NOTE |
Even though the text in the second <SCRIPT> block is intended for browsers that don't support scripting, it is necessary to specify JavaScript as the scripting language because of how Internet Explorer processes the script tag. Additionally, while Explorer also supports VBScript it doesn't permit "no-script" lines within a VBScript code block |
| TIP |
Because of a quirk in Microsoft's implementation of JavaScript, you can't mix the "no-script" technique and actual JavaScript code within the same script tag (a trick that Navigator allows). However, by simply moving the "no-script" code into a separate <SCRIPT> tag block, you avoid this problem |
This technique gives you the ability to code specific page objects, such as graphics, anchors, even plain text, that are displayed for different browsers, depending on what scripting language the browser supports, hence making it possible to handle both advanced and simple browsers within the same documents.
However, all browsers are not alike. For example, Internet Explorer 2.1 for the Macintosh does support frames and other advanced HTML features, but does not support JavaScript. In fact, Explorer 2.1/Mac treats the <SCRIPT> tag differently from any other browser-it ignores everything within the tag, whether the tag contains JavaScript code or "no-script" statements.
As such, trying to support all possible current browsers within the same document set is simply not possible, unless you're willing to sacrifice many of the advanced browser features.
If you want to use the latest and greatest Web technology and support the greatest number of browsers, one method is to split your site into two collections of documents, each optimized for a different type of browser. It's not necessary to create multiple versions for all documents-only those that make extensive use of advanced features or multimedia files. To automatically direct surfers to the pages best suited for their browsers, you need a "gatekeeper" or "redirection script." Using the techniques demonstrated thus far, you can create a gatekeeper front page that will perform the following:
Listing 1.5 demonstrates the overall structure of the gatekeeper.
Listing 1.5 A Gatekeeper Front Page
<HTML>
<HEAD>
<TITLE>GateKeeper</TITLE>
</HEAD>
<BODY>
<SCRIPT LANGUAGE="JavaScript">
<!--
if(navigator.appName.indexOf("Netscape") != -1) {
location.href = "netscape/index.html";
} else {
location.href = "microsoft/index.html";
}
// -->
</SCRIPT>
<SCRIPT LANGUAGE="JavaScript">
<!-- --><H1>Welcome!</H!>
<!-- --><HR>
<!-- -->This site utilizes the advanced features of
<!-- --><A HREF="http://www.microsoft.com/ie/">Internet Explorer</A>
<!-- -->and
<!-- --><A HREF="http://home.netscape.com/">Netscape Navigator</A>.
<!-- -->Download your copy now!
</SCRIPT>
</BODY>
</HTML>
| NOTE |
While this seems like extra work, depending on the site you're constructing, it might very well be worth it. If you're designing commercial sites, you'll probably encounter a client or two who wants everyone to have access to the site regardless of the browser they use-and still support all the advanced features that make the Web so multimedia-rich. You can, however, save yourself some work (and maintenance) with some judicious JavaScript coding. Because Navigator and Explorer both support the navigator object and it's appName and appVersion properties, you can "wrap" browser-specific pieces of code with conditional checks that make certain code work for one browser or the other. This effectively reduces your work from three distinct sets to two: JavaScript and non-JavaScript. Examples of this technique are found throughout the book. |
If you want to take advantage of both the latest Web technologies and still make your site accessible to those not using the latest browsers, you'll need to use some form of gatekeeper.
This chapter starts the adventure through the world of Web scripting by examining several techniques for screening surfers through a site based on the type of browser used. This provides an excellent basis for several other techniques. If you're interested in seeing browser screening in action, check out: