Browser-optimized Content Delivery | WebReference

Browser-optimized Content Delivery

Browser-optimized Content Delivery

Browser and HTML features are proliferating faster than mosquitoes in a swamp. Since different browsers support different levels of HTML, creating a single page optimized for all browsers can be problematic. Webmasters use the following methods to deal with this optimum content delivery problem:

Lowest Common Denominator (LCD)

By designing your pages with the HTML features that most browsers support you can be sure that most people will see essentially the same thing. The idea behind HTML is to allow a universal method of content delivery. By sticking to strict HTML (2.0 is the version nearly all browsers currently support) you can be assured that your pages will appear similarly on different machines and browsers. There are numerous efforts to quantify the LCD of current browsers.

The LCD method has one big advantage, you only have to create one set of pages. The disadvantage of the LCD method is that your pages can look pretty bland. Things will improve this summer, by then most browsers will support major HTML 3.0 features such as tables, background graphics, and JPEGs.

Netscape or Else

Many webmasters have taken the approach of designing their pages to work with Netscape and little else. Some have taken this Netscape or else approach to the extreme, giving error messages for non-Netscape browsers. This approach is flawed, as it limits your audience. Netscape may have 75% of the browser share now, but Microsoft may soon dominate.

Frames method - A more forgiving approach is to use <FRAME></FRAME> to wrap the Netscape top layer, and <NOFRAME></NOFRAME> to wrap the other browsers bottom layer. This solution was sent in by Mark Worsfold, thanks Mark.

Microsoft Browser Trivia - Microsoft has deemed it so important to be detected as Netscape compatible that they send a Mozilla-like environment variable in order to fool most web servers. Additionally, you can set your preferences to set what level of Mozilla compatibility.

Common HTML 3.0

A better approach than Netscape or Else is to utilize the HTML 3.0 features supported by Netscape 2.0 and Microsoft, and to avoid browser-specific tags. Some of the features common to Netscape, Microsoft and HTML 3.0 are: tables, alignment, and the background attribute to the body tag. Netscape-specific tags are frames, font, blink, center, bgcolor and text colors. The IETF [1] has incorporated some Netscape extensions into the HTML 3.0 draft [2], and will no doubt adopt more (like frames). Until they do, using the HTML 3.0 features supported by the major browsers is a good compromise.

The common HTML 3.0 method has the advantage of allowing you to deliver good looking pages to the majority of users (80-85%). The disadvantage is that older browsers don't support some HTML 3.0 features, most notably tables. This situation is changing rapidly, as AOL and Compuserve have licensed both Netscape Navigator and Microsoft Explorer.

Browser-optimized Content Delivery

Many solutions have been proposed to deliver the optimum page for each visiting browser. In each method, alternate pages are created either manually or on the fly. These solutions have the advantage of delivering optimized pages for different browsers but the disadvantage of increased complexity and maintenance costs.

Multiple Pages

The multiple page method is the most common method to optimize content delivery. The webmaster creates different sets of pages that correspond with different browser and/or bandwidth capabilities and directs users either manually or automatically. An example of this multibranched tree method is WebPlanet. Another approach is to create HTML 2.0, HTML 3.0, and Java/Shockwave/Whatever's the latest technology pages. The multiple page method requires two to three times the maintenance as a single set of pages.

Manual Page Navigation

One simple method to negotiate a parallel tree is a gateway page that directs the user to "click here for a text version" or "non-Netscape" or "Netscape" or "low bandwidth."

Automatic Page Navigation

A better approach for the user is to automatically move to the correct page. Various methods have been proposed to accomplish this, including:

Default redirect script
#!/usr/local/bin/perl
if ($ENV{'HTTP_USER_AGENT'} =~ /^Mozilla/i) {
print "Location: https://www.webreference.com\n\n";
} else {
print "Location: https://www.webreference.com/indextxt.html\n\n";
}
exit 0;
 Pros: Transparently moves to proper page for different browser capabilities.
Cons: Requires root access, all your files will be executable so your entire web site would have to be script driven. Must update script as browser capabilities change.
Server side include
Create an .html file tht contains the following line:
<!--#exec cgi="redirect.cgi" -->
Pros: See above.
Cons: Server side includes with exec on is a possible security risk
Create a symbolic link between index.html and redirect.cgi
Pros: No need to have entire site script driven, see Default Redirect Script.
Cons: Instead of executing the script, this method returns the text of the script.
Client-pull Method
Create an LCD index.html file as the default page for Lynx, AOL, and other limited browsers, and use a client-pull to send advanced browsers to the alternate page (Netscape, NCSA Mosaic, Internet Explorer).
Pros: This method is the easiest to implement and does not require root access or programming.
Cons: There will be some delay when switching pages for the majority of your users and an additional load on your server. Not all advanced browsers support the same feature set.

Automatic Content Negotiation

The best solution to optimizing content delivery is to create custom pages on the fly. There are two ways to accomplish this, using the user-agent environment variable or HTTP Content Negotiation (MIME-based).

User-agent method

The server, using the HTTP_USER_AGENT environment variable, recognizes the type of browser that is requesting the page and creates a customized page, optimized for that particular browser. CGI scripts can be written to accomplish this task, or you can use a package like HTMLScript, or HoloWWW Extended HTML. These higher level scripting languages allow anyone who can program an IF THEN ELSE statement to perform many tasks easily, including browser-specific pages.

The disadvantages of the user-agent method are:

Luckily, there are existing, current databases of browser capabilities that webmasters can use. [3].

Webreference.com now employs user-agent content negotiation using HoloWWW Extended HTML. By inserting a few lines of code into a special Welcome.heh file table or non-table versions of the home page are created automatically. Here's the code:

{if {browser |tables}}
<TABLE>....
{else}
Non-table version
{endif}

HoloWWW Extended HTML is only available on HoloNet servers, but webmasters can roll their own with HoloNet's browser capability registry [3].

MIME-based HTTP Content Negotiation

With HTTP content negotiation the client and server actually negotiate, via MIME types, on what that particular browser can accept, and what that particular server can give. Once they reach an agreement, the request is granted. This "built-in" content negotiation would eliminate the need for browser capability databases. Unfortunately, only a few servers support this feature (Apache and W30) and even fewer browsers fully support it. For more details on this technology, consult Brian Behlendorf's HTTP Content Negotiation article [4].

Conclusion

Designing web pages is usually an exercise in compromise. With automatic content negotiation you can have your cake and eat it too. One HTML page can have customized behavior for different browser capabilities.

References

(1) The Internet Engineering Task Force (IETF)
Sets Internet standards. For more information refer to the HTML Specifications area.
(2) Netscape tags and attributes adopted by the IETF
include IMG WIDTH/HEIGHT, TABLE WIDTH, BORDER, ALIGN, and CELLPADDING/SPACING, BODY BACKGROUND. This list was compiled by the author from following the HTML/NHTML specifications over time. For more details refer to my HTML 3.0 and Netscape 2.0 article.
(3) The browser capability registry
HoloNet maintains this public-domain resource of browser capabilities and accompanying Perl code.
(4) What is Content Negotiation?
An overview of HTTP content negotiation by Brian Behlendorf of Organic Online. Brian is one of the authors of the popular Apache server, a much-improved version of NCSA's HTTP web server.


Comments are welcome
Created: Apr. 6, 1996
Revised: May 6, 1996