Browser Sorting

Browser Sorting - An Introductory Tutorial

What is It?

Browser Sorting is a group of techniques that can be used to provide web documents and specific web document contents to a web browser that are directed to the capabilities of that browser or family of browsers.

Why is it Necessary?

Being blunt, it isn't, but, if you need to exercise even a moderate amount of control over the appearance of your pages or if you need to have active content on them, it becomes so. Web browser capabilities vary widely and none of them follow the current imperfect web page standards perfectly. (I'll write a rant about web standards later.) All of them have different capabilities, render some things differently, and have their own bugs. Some older browsers can turn perfectly valid pages into illegible trash. If you want to provide access to your pages for as many browsers (users) as possible you must either give up almost all control over their appearance and behavior or somehow cause different browsers to display your pages as you intended. If this sounds like a challenge, it is!

Part of the reason this situation exists goes back to the browser wars a few years ago and two specific browser manufacturers, Microsoft and Netscape. In their battle to try to control the browser market, both, decided to attempt set their own extended standards for web page content, while not paying enough attention to the existing real standards, particularly for CSS. (Styles) My opinion is that Netscape was probably the worst offender as the version 4 and 5 browsers dealt with styles horribly. This was a serious disservice to both Internet Users and Web Developers.

Additionally, people don't just use the Internet with newer personal computers. There are a lot of older Macs and Nix systems out there that are still working well. Some people are still using Web TV. Internet use with devices like cell phones, palm tops, personal information managers, game systems, etc. is becoming common. These devices may not have the capabilities of a regular web browser and accessibility of content for them is becoming more important. Browser sorting is an important mechanism for providing that content.

Realize that browser sorting is not the only way the circus of browsers out there can and should be dealt with. Every web design project should start with the selection of standards that it will follow and all pages of that project should be strictly coded to those standards! Doing this is critical to providing pages that are as accessible as possible to the intended target.

Some Available Sorting Technologies

It has been recognized that the need to identify client capabilities existed almost since HTML document transmission started. Even early versions of the HTTP Protocol specify that file requests made to an HTTP Server (Web Server) should include client identification information. This information is provided to the web server in more or less plain text as part of every request made of it and is referred to as the Client or User Agent Identification String. Client ID Strings can be as simple as: "Mozilla/1.0" or they will more typically look like the example below which is your Client ID String.

Your Client ID:

Use of the Client ID String to determine Web Browser capability can be done on the Web Server. Newer versions of Microsoft Internet Information Server (Microsofts Web Server software) and properly configured Apache Web Servers have the ability to use a browser capabilities database file (browscap.ini) and similar technologies to provide appropriate, browser family specific pages to clients making page requests of them. There are several problems encountered when using server based browser sorting.

First: Your site becomes server specific. It must be provided by the same web server software that has been configured in the same way. Moving your site to another server, becomes a nightmare. This is a serious issue if you are dependent on a leased server.

Second: Browsers are constantly changing. New ones appear. The browscap.ini file, etc. on the server needs to be updated and pages can need to be rewritten.

Third: Some Browsers Lie! Some Browsers provide False Identification Strings and I have yet to see one of these browsers that is truly able to mimic the browser it is pretending to be. Konqueror, which is one of the most common Linux and Unix browsers, and Opera, which is available for a wide range of operating systems, (including cell phones) are both are capable of doing this.

With these issues being present and with the complexity of implementation, it is difficult to recommend using server based sorting to add extra control over site appearance and functionality to a normal web developer. It will not be discussed any more here.

There are several other browser sorting mechanisms that I am comfortable with. All force browser capability identification onto the browser where it probably belongs. All involve the use of scripts as part of the page content and I need to rant about that a little before continuing on.

Scripting Rant

First: How scripts are properly identified in an HTML document has changed. Scripts used to be identified as follows.

This is not fully valid HTML 4. In newer versions of HTML the language property is deprecated (marked for removal from the language) and has been replaced with the type property, which is intended for use as follows.

The newer and more appropriate example above will cause the entire script not be recognized by some older browsers and this can be advantageous when using a client side script for for browser sorting. The browser simply can't be redirected, if it doesn't read or can't understand the redirection command. You will find this logic to be a common theme here. It is also important to note that the language and type properties allow use of generic languages as in the example above or specific scripting language versions such as JavaScript1.2.

Under some special circumstances it can be helpful to use both the language and type properties in a script open marker. If you decide to do this, it is probably best to always use the language property first as in the example below. Properly built web browsers ignore what they don't understand!

Next: Script contents should always be hidden from browsers that don't understand them. This should be done with hide or comment markers as shown in the example below.

Finally the Rant: Because the world of browsers and their ability to interpret scripts is such a zoo, all good quality scripts should include some type of error handling. Having your web pages present and harass their viewers with error dialogs and messages is totally unacceptable. Modern Javascript enabled browsers can be told to ignore errors in a script by starting it as the example below demonstrates.

Having a Javascript on a page, that has not been previously browser sorted, that does not include error handling is simply not appropriate. You'll discover, I rant a lot about error handling!

VB Scripts use a different error handling system, but it can also be simple to code. With a VB script it is important not only to tell the browser to keep going if it encounters an error, but to also clear the error object. This is demonstrated in the example below.

It should also be noted that the error object can need to be cleared with Err.Clear when exiting subroutines and terminating the script, because instances of the VB Scripting Engines can have an ugly habit of remembering past errors.

Hopefully, the preceding scripting basics will help you both to write good scripts and to more properly evaluate scripting examples that you may find on the Internet. There is a lot of old stuff out there that is currently improper and being maintained by sites that are designed to generate advertising revenue, not provide current content. There are also sites providing scripts for the purpose of installing spyware on your or your sites users computers. Avoid Script Sites that reek of existence for marketing revenue. Never download and use a script that you haven't read and understood!

Back to Sorting Technologies

Browser sorting on the client can be handled in two basic ways. Pages can be designed so that different browsers interpret their contents differently or separate pages can be built for different families of browsers with redirection sending the browsers to appropriate pages.

The first technique involves being very selective with the HTML and CSS used, the identification of appropriate browser functionality and the provision of separate script segments for different browser groups. It can work well for dealing with a few appearance or functionality issues, but if it is used extensively page size and complexity will grow radically. Development and debugging, cost and time can become serious issues. With one exception, Conditional Comments, doing this involves a detailed understanding of scripting and I am not going to that depth in this document.

The second method involves creating separate pages for different groups of browsers and having a sorting page direct browsers to pages that are appropriate to them, leaving browsers that do not support the desired functionality on a set of generic pages. If you are going to do this it should be done with practicality and minimality. Minimize the browser sorting your site does. Sort browsers on site entry only, unless you have a very specific purpose for doing otherwise. The last thing you should do is to build ten different versions of every page on your site. Two or three versions will almost always be adequate. Sort browsers by as general of groups as possible! (KISS) Spend some time building good page templates for each version of your site. Realize planning is everything here! Maintain page content separately from the pages as much as possible. Use a word processor for textual content and develop an image library system. Copy and paste content into templates when building pages. If you need to do a lot of pages for different sorts create or find content conversion utilities for the different sorts you are using and use them. The process can be done with less work than it would initially seem.

The remainder of this article will focus on the second method of client side browser sorting and will start by trying to provide an understanding of redirection. Redirection is really at the heart of it.

An Introduction to Conditional Comments

Conditional Comments are a feature of the newer versions of Internet Explorer, specifically V5 and above. Conditional Comments are HTML comments that contain a conditional test and code that will only be executed by an appropriate version of the Internet Explorer. While they can be quite elaborate, it is hard to recommend making them so, as page bloat could quickly become excessive. This page is an example of what I consider to be appropriate use. It uses a Conditional Comment to load a second Style Sheet to deal with an IE form button rendering problem. They can also be appropriately used in a similar fashion to deal with IE Box Model issues, if page design requires it. Conditional Comments allow you to build pages that deal with some IE specific issues and that will still validate to the W3C standards.

The example below is the Conditional Comment used for this page. The first line tests to see if the browser is a version of IE that supports Conditional Comments. The second line loads a Style Sheet containing IE specific property assignments that deal with the specific rendering problems, if the browser is a supported version of IE. The third line closes the conditional block and comment.

Basic Conditional Comment Example:

The best source for current and accurate information on the use of Conditional Comments is the Conditional Comment Section of the MSDN Library. Be aware that the problems you need them for the resolution of may not be acknowledged there. While Conditional Comments may provide a mechanism for the solution to a problem, you will probably have to find the solution itself by searching elsewhere or experimentation.

Understanding Client Side Redirection

Client Side Redirection is the process of a web page transferring the browser to another web page. There are several code mechanisms available for doing this and there are, to me, right and wrong ways of doing it. An improper redirect will prevent the browser from escaping a page by using its back method unless the user can issue it at least twice very quickly. This can be horribly confusing to users. Proper redirects can be backed out of. Improper redirects may also open a new browser window for the new page. While there are a few situations in which doing this may be acceptable, it is not acceptable for a normal redirect. Improper redirects won't be discussed here, but be aware they exist.

The simplest method of redirection uses a meta tag in the head section of a page. The W3C committee recommends against its use, but I have found it to be as close to 100% browser compatible as anything in the web development world. In other words, this seems to work with all browsers. A very simple example of this tag in use on a transfer page is show below. The new location can be a local page or a full URL pointing to a page anywhere. The refresh attribute value tells the browser it should reload this page from the new location. The 0 in the content attribute value represents the number of seconds the browser should delay before doing so. The url= section of the content attribute value is where you specify the Local Page or the Full URL of the Page you want to transfer to. Refer to the W3C HTML Specifications for more information.

Basic Redirection Example:

<html>
<head>
<meta http-equiv="refresh" content="0;url=NewPage.htm">
</head>
<body>
<h4>If the page you requested does not start to display within
the next 10 seconds <a href="NewPage.htm">Click Here!</h4>
</body>
</html>

The previous example works for redirecting all browsers, but that doesn't help if you only want to redirect specific browsers. It works great if you move your site to a new location and want to redirect everyone to it.

The real key to redirecting specific families of browsers properly, lies in selective redirection using a script. This can be done by issuing a redirection command that only the desired browsers will understand or by determining if the desired capabilities are available and then redirecting desired browsers as needed. There are a number of redirection commands available.

Some of the most common ones include:

location.replace("destination.htm");
window.location = "destination.htm";
location = "destination.htm";
url = "destination.htm";

I try to avoid all except location.replace as it is generally the most acceptable for newer browsers.

The location.replace method does exactly what it sounds like. It loads the specified page in the browser and replaces the page containing it with the specified page in the browsers history. The following section will provide some of my favorite browser sorts with explanations, but be aware this is a limited tutorial and it cannot begin to demonstrate and discuss all the ways browser sorting can be done.

A brief warning here: Using location.replace on a frames page or within frames is not a good idea. How specific frames are referenced programatically varies with different common browsers and dealing with it requires browser specific code for all the common groups on every page where it is used. ARG!!!

Some Client Side Browser Sorting Basics

It is easy to ask the browser both what it's name is and what version it is from a script on a web page. The problem with doing this goes back to the fact that some browsers provide incorrect information when you do. I really prefer to use functionality or other tests to determine what the capabilities are of a browser accessing my pages as the rest of this document will demonstrate.

When you attempt to redirect different families of browsers to different pages for scripting functionality purposes, you are typically in reality, attempting to discover what DOM(s) (Document Object Model(s)) a browser supports and then redirect it to a page that is written for a specific DOM. The real trick to client side browser sorting is writing code that will be recognizable and executable by specific families of browsers and will at the same time not cause other browsers to misbehave. This is a real challenge, but it is a challenge that can be achieved. Some of my favorite little tricks are shown below. Remember to KISS as you will really pay for over-complication when doing this.

The Internet Explorer running on a Wintel computer (A computer using some version of the Windows Operating System and an Intel or clone processor) is definitely the most common browser and operating system combination currently in use. Like it or not for now this is a sort that you should probably use if you are going to browser sort. The example below redirects newer Wintel Internet Explorers (hopefully version 4 and above) using the location.replace method to a different page, while leaving all other browsers, including Mac Internet Explorers and Web TV Browsers, on the current page. It works by using a VB script to do the redirection and as Wintel Internet Explorers are essentially the only browsers that can interpret VB script, it is very safe. Note: VB scripting capability was and I assume still is available for IE on Macs, but it has to be deliberately added and I know of no users that have done so. IE on a Mac is not Wintel IE and you are probably much better off treating it as a generic browser, which the following sort allows you to do. Note also: It is quite acceptable to use JavaScript or Jscript for active content on pages built for this sort, just be sure to use the MS DOM for component references and not to get to tricky with your code.

Wintel IE sort example:

<html>
<head>
<script type="text/VBScript">

</script>

It's that simple! The real challenge is writing those pages to take advantage of the now available special features. The MSDN Library provides lots of good reference material for helping you to learn to do so.

The W3C DOM should be given serious attention as its availability should soon surpass, if it hasn't already, the availability of the MS DOM. The W3C committee finally specified a standard DOM and browser developers are implementing support for it in their browsers. IE has been supporting it since version 5 and the Mozilla based browsers have been supporting it for a while. While it does not provide quite the features and flexibility of the MS DOM, its use allows you to create very dynamic and attractive pages that should eventually be accessible to users of almost all browsers and operating systems. This one is important and learning to build pages for it is important! W3C DOM specifics are available from the W3C Site at www.w3.org.

The example below demonstrates how to sort out browsers that support Javascript and the W3C DOM by attempting to access a property value by Id of a nested tag. It is not as simple as it could be, but it is safer because of it. Support for the W3C DOM is partial at best on some older browsers and the following test goes to a little extra effort to verify a basic level of that support in determining that tag attributes really can be accessed. Notice the inclusion of the error neutralization code for JavaScript capable browsers that don't recognize the DOM test code.

W3C DOM sort example:

<html>
<head>

</head>
<body>

<span id="nestTest"><span id="docTest" title="Arg!"></span></span>
<script type="text/javascript">

</script>
<-- Body content for browsers that failed the test -- >

With luck this is where the future lies!

The following script relies soley on the location replace method and can be used to sort out browsers that provide reasonably good CSS level 1 support and Javascript support for one liners in tag event properties. It may leave a few capable browsers behind on a more generic page, but that is far better than directing other browsers to pages they can't display. If they didn't lie about they're capabilities we wouldn't have to deal with dilemmas like this! This script can be located in either the head or body section of a page.

Basic CSS1 and Javascript support sort trick:

Browser sorts can be combined into a single script. In other words a single script can contain redirections to several different locations. If you decide to do this be careful as test order is important and remember that more sorts means more pages. Some browsers provide support for more than one Dom. Be sure that specific browsers are being directed to where you want by testing your site with different browsers. Enough said on that subject!

The script below represents a browser sort with multiple destinations. It first sorts out browsers that provide basic W3C DOM and JavaScript support, then browsers that are left that support the MS DOM, then browsers that hopefully provide support for basic W3C standards, with browsers that failed all tests being left behind on the current page. Note: Unlike the previous sorting script, this one can be used in a documents head or body section.

Multiple destination sort example:

Note: The comments are there for you and should be removed in any pages that you use these scripts in.

Hopefully this has provided you with an acceptable introduction to browser sorting. If you want to learn more at least you now know some of the terms to search for using that Google It Button on the bottom of the page.

JimD