Chapter 1 : Browser Identification
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 ******ing tricks that can make your life a bit easier.
Server-Side Screening
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 ****** to identify the user's browser and force-feed the proper pages.
High Bandwidth/Low Bandwidth
The first technique is still in use today on many sites (see fig. 1.1). Three valuable uses of it are:
- Provide the option to switch to a text-only version of the site for speed surfing.
- Provide "******ed" versus "non-******ed" access to your site, to make the best use of advanced browsers while at the same time allowing older browsers to surf.
- Offer heavily graphic (for users with hardwired or T1 connections) and lightly-graphic (for slower modems) paths through your site.
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 "****** surfers" that may be using any one of several different ******ing 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 ******ing 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!
CGI Wrapping
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 ****** instead of the HTML file directly:
"Enter the site"
Clicking a link forces the server to launch the CGI ******, 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 "; open (HTML, "<", $htmlFile); while () { print; } close (HTML); exit (0);" While the ****** in listing 1.1 is very simple, this method also creates some problems, such as:
- You need to edit this ****** every time a new browser type appears. This may often require tracking down a copy of the browser itself or perusing the site's access logs to determine what the new browser transmits for a user agent ID.
- Because this ******, and the HTML page that calls it, rely on the user clicking the links, your carefully planned front door ****** can be completely bypassed by the user entering a specific URL.
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 ******ing tools has made this job easier.
Client-Side Screening
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.
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:
- Reload the current page after a period of time
or
- Load a new page after a period of time
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: .
The (HTML) tag, one of the more esoteric HTML tags, is used within the header block (as defined by the HTML ... 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 tag would be:
""
The two attributes of the tag are:
- HTTP-EQUIV must be set to "Refresh" to activate client-pull.
- CONTENT consists of a number that specifies the number of seconds to wait before pulling the next page, and a URL= element that identifies the page to pull.
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.
| 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 ******ing.
Client-Side Scripting
Client-side ******ing involves one of two languages: VBScript (from Microsoft) or JavaScript (from Netscape). In both, the ******ing code is embedded directly into the HTML document, and contained within a <******> tag block:
<****** LANGUAGE="JavaScript">
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 ******ing ignores the tag but still displays the ****** statements as text for display. To hide the ****** body from these browsers, wrap the entire body of the ****** 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 () 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: <****** LANGUAGE="VBScript"> |
Even though both Navigator and Explorer support JavaScript, Explorer doesn't fully implement the language. Therefore, if you're going to do heavy Java ******ing 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 ******ing. 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
<****** LANGUAGE="JavaScript">
At this point, there's only one more case to cover before the client-side gatekeeper is complete: browsers that don't support ******ing (such as Mosaic). Because a page containing JavaScript has to be loaded and processed, it's desirable to prevent the no-****** version from displaying in Navigator or Explorer. This is accomplished by using a With the release of Navigator 3.0, Netscape coined several new HTML tags, including While the JavaScript interpreter looks inside the comment tag block for its ****** code, it has the unique ******** 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 <******> tag and get an HTML statement that JavaScript (and browser) ignores, but displays to non-******ing browsers. This effectively creates the equivalent of a
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 ******ing 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 <******> tag differently from any other browser-it ignores everything within the tag, whether the tag contains JavaScript code or "no-******" 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 ******." Using the techniques demonstrated thus far, you can create a gatekeeper front page that will perform the following:
Faking
Listing 1.4 Creating a
<****** LANGUAGE="JavaScript"> <****** LANGUAGE="JavaScript"> Non-Script browsers will process this
NOTE
Even though the text in the second <******> block is intended for browsers that don't support ******ing, it is necessary to specify JavaScript as the ******ing language because of how Internet Explorer processes the ****** tag.
Additionally, while Explorer also supports VBScript it doesn't permit "no-******" lines within a VBScript code block
TIP
Because of a quirk in Microsoft's implementation of JavaScript, you can't mix the "no-******" technique and actual JavaScript code within the same ****** tag (a trick that Navigator allows). However, by simply moving the "no-******" code into a separate <******> tag block, you avoid this problem
The Completed GateKeeper