Made for Each Other? Making Your Site Browser Compatible

Robert Hess
Developer Relations Group
Microsoft Corporation

June 2, 1997

The following article was originally published in the Site Builder Magazine (now known as MSDN Online Voices) "More or Hess" column.

I often find myself talking with people about the new features coming in the next version of Internet Explorer, or available from Windows NT Server, for serving up Web pages. After I've showed them the cool new features, and described how they might be used in a Web document, people usually get anxious to try a new feature on their own sites.

Then the question always comes up:

"How do I get this to work on the browsers currently available?"

I just look at them with a blank stare. If you could do this with a current browser, it wouldn't be a new feature, now would it? It always amazes me how, on one hand, Web developers clamor for some special, whizzy feature that they think would really improve their Web site, yet they want it to work on every browser their audience might be using.

It can't be ignored that compatibility, however frustrating for Web designers and browser developers, is an important issue that needs to be considered carefully. It can also be a very, very difficult problem to solve. At some point in your Web design, you will have no choice but to alienate some faction of your potential audience, either by adding a feature they can't see, or by making a site so simple looking that surfers seeking "entertainment" will ignore it.

There are several ways to create a Web site that provides an appropriate level of compatibility from platform to platform, and browser to browser. Let's take a look at a few different approaches; perhaps one will be appropriate for your projects.

Start Simple

Create a Web site focused on the "Lowest-Common-Denominator" approach. This means the site doesn't use any fancy HTML, or rely on embedded applets, or client-side scripting. It's just information, simply presented but well structured. Actually, creating a "generic" but representative site is a pretty good exercise to check the quality of your message and information. Far too many sites rely so heavily on special effects and fancy graphics that their creators don't realize how little real information they provide.

Once you have set up an HTML 2.0 version of your pages, then you can start adding some visual features that allow newer browsers to utilize some of their functionality. This can easily be done in a compatible manner with things such as the <FONT> element, for affecting the color and typeface of the text, and the <TABLE> element, for helping fine-tune the layout of the page. And, of course, there is always the <IMG> element, but remember that some surfers still use text-mode browsers--so, if you really want to make your pages backwards compatible, be careful how you utilize this.

Cascading Style Sheets

As Cascading Style Sheets (CSS) become more common, you can create some nice rendering effects. However, it is very easy to get into compatibility problems with CSS, so be careful how reliant your content is on the form you give it. I do this by simply commenting out the <STYLE> block of the page I am working on, in order to test its rendering. If you avoid using the STYLE attribute within your page (use CLASS instead) you can quite effectively turn off all style-sheet features of your page and ensure that you haven't accidentally added any CSS-specific features.

Client-side Scripting

Occasionally, you may really, really want to add something that won't quite work on older browsers. One example is if you want to utilize the margin settings of CSS to create a shadowed-text effect. With CSS, this can be done by drawing the text first in the shadow color, then drawing the text a second time in the foreground color--but first positioned over the top by adjusting the margins. Unfortunately, this results in the text being displayed twice (or more, if you are doing a fancy shadow) on browsers that don't understand CSS. But if I utilize client-side scripting, I can code this so that the second occurrence of the text comes from the script code, and thus won't appear on older browsers.

Here is a simple example.

Shadowed Text

It is fairly common to use Visual Basic® Scripting Edition (VBScript) or JavaScript to do in-stream page rendering, utilizing the document.write method like this. Done right, it can greatly increase the flexibility of your pages.

Browser Sniffing

In the above example of shadowed text, I used "browser sniffing" to determine when to utilize CSS. In this particular case, I simply relied on VBScript to render the CSS-specific code. Now that Netscape will also support CSS, this code would need to be a little more robust to truly utilize CSS on all browsers that supported it.

In client-side scripting, you can access the "navigator" object to help you determine in which browser, and in which version of the browser, your page is currently being rendered. With that information, you can do a number of things to present a compatible page. But avoid simply redirecting the page to a page for that specific browser. This would prevent the user from simply using the "Back" button to back out of your site, since each time the user backs up through such a redirect page, it slams them back into your site. While you might not mind this, the user definitely would.

Server-side Rendering

The best and most common place to utilize browser sniffing is on the server. When a Web browser requests a page from your site, several pieces of information are passed along with the request. One is the "UserAgent" string, a text string that attempts to identify the browser being used to assist the server in presenting the appropriate information. In order to leverage the UserAgent string, you need access to server-side programming of some sort, either in a CGI application, a Perl script, an ISAPI application, or via Active Server Pages. But once you've tackled that, a lot of options are available for providing the user with backward-compatible pages.

Multiple Trees

Another common way to achieve compatibility with other browsers is to provide several different versions of your site.

You could design one for simple, text-mode browsers, one for limited graphical browsers, one for browsers that support frames, and another for browsers that support embedded Java applications or ActiveX controls. While I don't necessarily recommend writing a half-dozen versions of your site, such an approach might be appropriate, depending on how you balance your need for compatibility against your wish to utilize advanced features of the browser,. And, while you could simply use server-side browser sniffing, which automatically redirects the user to the version of the site best suited to that browser, this isn't necessarily recommended. Consider allowing the user to select his or her own tree to view, since the text version and non-frame version of your site will most likely download and render faster then the more advanced versions. Not everybody is using a T1 line for Internet connections, so if you are going to go to the trouble of creating multiple ways to view your information, you might as well let the user select which view to use.

Database Templates

One way to increase the flexibility of your site is to leverage a database for rendering as much information as possible. If your content comes from a database, it can be relatively simple to create and manage multiple versions of your site simultaneously. By carefully creating appropriate templates, you can easily publish a site as simple or as complex as you want. Combine this with all of the above methods, and you suddenly have a very rich and broadly targeted way to provide your information to as many people as possible. And since there are many different ways to populate a database, it is often easier to manage and update your site then if the entire site was simply contained in raw HTML.

Your Call

Only you can make the right choice for your specific implementation and abilities. Just remember that compatibility doesn't come for free. Sometimes you need to leave some segment of the surfing population behind to take advantage of some specific feature or technology.

Robert Hess is an evangelist in Microsoft's Developer Relations Group. Fortunately for all of us, his opinions are his own and do not necessarily reflect the positions of Microsoft.