Make your Web Site Cross-Browser Fit!

Make your Web Site
Cross-Browser Fit

A web site that is not compatible with a visitor's browser is a major deterrent to your visitors. How can you avoid it? - This article shows three easy ways to do that.

Most web sites are developed for MS-Internet Explorer. Simply because it offers the most flexibility for JavaScript, DHTML, etc. True, some other browsers also have Java enabled. But their capabilities for DHTML and other niceties are limited. So, just as a matter of economy, it will be clever to distinguish two major groups of browsers:

MS-Internet Explorer (IE)

non-IE-compatible browsers

At www.thecounter.com/stats you can see that currently about 90% of all browsers on the web are different versions of IE, 5% are Netscape (NS), 5% others.

As a rule, for making your web site cross-browser fit, you should be able to view your html-files in at least one NS-browser. You can download one free from home.netscape.com/computing/download/ , www.opera.com and other sites. When installing it, make sure not to have checked "Make Default Browser" - thus your current default browser will be left unchanged.

The easiest way to decide what kind of browser a html-file is displayed on, I found, is: Provide an additional attribute within the <BODY>-tag of your document, such as the following.

By that any of your visitors' browsers is directed to execute the JavaScript function CheckBrowser(…) upon loading the document. (A browser that has no JavaEnabled still can execute a JavaScript function, unless it displays its results on the screen.)

Then you have three possibilities to make a page of your web site cross-browser fit:

Doorway Page

Separate Versions

Dual-version Page

Doorway Page

For this method you need three htm-files for each page:

IE-version
NS-version (for Netscape and all the other non-IE-browsers)
doorway page

The doorway page is an empty page holding only the JavaScript function CheckBrowser(…) mentioned above and a tag <BODY onload="CheckBrowser(…)"> . When it is loaded, it is decided which kind of browser there is, whether IE or NS (to summarize all non-IE-browsers). Accordingly, the respective version is loaded.

So, the function CheckBrowser(…) could look like this:

function CheckBrowser()
{
  var ie = (document.all)? true:false;
  if (ie)  window.location = ..._ie.htm;
     else  window.location = ..._ns.htm;
}

When this function is executed, the browser version is determined by the collection

document.all

If it is non-zero, it's an IE-browser. Consequently the IE-version is loaded, with all the "elegant" features that are possible under IE.

If document.all is zero, we are in a non-IE-browser. Consequently the NS-version is loaded, in which the navigation should be handled quite simply:

At the top of the document there could be a horizontal menu with links to all the chapters' titles, such as

<A HREF="#bookmark1">chapter 1</A> | <A HREF="#bookmark2">chapter 2</A> | … | <A HREF="#bookmark_n">chapter n</A>
At each chapter's title there should be the respective bookmark:

<A NAME="1">Chapter 1</A>
<A NAME="2">Chapter 2</A>
:
<A NAME="n">Chapter n</A>
At the end of each chapter, there should be a link to provide an easy way for the visitor to jump back to the menu at the top, possibly to jump from there to another chapter:

<A HREF="#top">top</A>
At the top of the document, before the horizontal chapter menu, there should be the respective bookmark:

<A NAME="top"></A>

Advantages of a doorway page:

This is the most unobtrusive way of providing different versions of a document, adapting itself to the visitor's browser. The doorway page is loaded, and a moment later the correct version comes up on screen. Only the most attentive visitors will even notice that something has changed on screen (by watching the browser's "Address:"-line).
This is the fastest way to present the correct version, according to the visitor's browser - independent of the individual versions' complexity. So, it is virtually the only way to do it with very complex documents.

Disadvantages of a doorway page:

The most obvious disadvantage of this method is that you need 3 htm-files for each page. With a great number of pages on your web site, you tend to get swamped by a flood of htm-files.
Data Integrity: When you have to change the contents of your document, be sure to update them in both versions.
It's a good idea to stick to some discipline when naming your files. A good way to do that is:
- naming the IE-version with suffix _ie
- naming the NS-version with suffix _ns
- naming the doorway page without any suffix

If your web site has many rather simple pages, you might consider using any of the other two methods.

next top

Separate Versions

You might wonder: "Why an empty doorway page? Couldn't I have the NS-version with a <BODY>-tag just like the one above, which would be swapping itself against the IE-version once an IE-browser was detected?"

Of course you could.

Then the function CheckBrowser(…) is even simpler:

function CheckBrowser()
{
  var ie = (document.all)? true:false;
  if (ie)  window.location = …_ie.htm;
}

Advantages of this method:

You can save on htm-files. You need only two htm-files per page:
- the NS-version = doorway page, without any suffix
- the IE-version (with suffix _ie ).

Disadvantages of this method:

Data Integrity: When you have to change the contents of your document, be sure to update them in both versions.
During the execution time of function the NS-version still is visible, even on an IE-browser. Your visitors might be able to read the first few lines of it.
That might cause frustration to your visitors. They are reading right in the middle of a sentence, then the page is swapped, perhaps for something looking completely differently.

If you have a very large web site, you might want to save htm-files wherever you can. For that reason, or to avoid the disadvantages mentioned above, the third method might be good for you:

previous next top

Dual-version Page

If you don't shy away from some HTML-coding and JavaScript-programming, you can even combine IE- and NS-version in one htm-file.

I found it best to start out with the IE-version. In its <BODY>-tag place, as usual, the function CheckBrowser(…) :

Now. however, that function needs to be more complex:

function CheckBrowser()
{
  var ie = (document.all)? true:false;

  if (ie)
   for (i=0; obj = document.all.item(i);  i++)
   {
      if (obj.className == '')    continue;
      if (obj.className == 'IE')  obj.style.display = '';
      if (obj.className == 'NS')  obj.style.display = 'none';
   }
}

Finally, into your htm-file you should code all those features that are to be visible on NS-browsers only. If they comprise one object only, code it with the attribute CLASS="NS" . Objects that are to be visible in IE-browsers only should be coded with attribute CLASS="IE" STYLE="display:none"

Features that comprise several objects should be coded within brackets <DIV CLASS="NS"> … </DIV>

Hint: I found it good to have comments at the end of such DIV's:

<DIV CLASS="NS">
            :
</DIV> <!-- end of CLASS="NS" -->

Once you are working with more complex dual-version htm-files, you will be happy to have everything clearly arranged.

Similarly you can have a set of objects to be displayed only in an IE browser but to be hidden under NS. They should be bracketed as follows:

<DIV CLASS="IE" STYLE="display:none">
            :
</DIV> <!-- end of CLASS="IE" -->

Advantages of the dual-version page:

You need only one htm-file per page. For a very large web site this is the best that you can get.
Data Integrity: When you have to change the contents of your document, they are updated automatically in both versions.
In some applications it might be necessary to have a compact document, apt to all browsers, housed in one htm-file only. Then the dual-version page is what you should do.
Unless your document is very complex, your visitors will not notice that it is adapting to the browser. So, if you want to have it done covertly - implement it as a dual-version page!

Disadvantages of the dual-version page:

Execution of the function CheckBrowser(…) is taking time. Even more so because it has a lot to do now, depending on the complexity of a page. With a very complex page this can be irritating to your visitors: What first comes up on screen is the NS-variant. Then, after a noticeable time span, it suddenly changes to the IE-variant.

updated Feb. 11, 2003:
This becomes even more of a problem if you have any kind of navigation menu (see e.g. article GhostMenu, FollowMenu: ...), a UserMenu (see e.g. article UserMenu - A Host of User Interactivity in a Nutshell) or a number of custom functions in your HTML file. Then your document will require some seconds of setup time - the time from completion of loading until your document becomes fully available to your readers. During this time they will see the NS-parts, might be tempted to click on them - but nothing happens. It's more user-friendly to avoid that. A handy method to do that is described in section Dynamic Creation.
It means some concentrated work for you to prepare a dual-version htm-file. With time many online documents tend to grow in complexity. Sooner or later you might ask yourself if it wouldn't be more economical to have separate versions for IE and non-IE. Moreover, then you could specifically address the situation of IE- and non-IE users. (E.g. obviously it's not clever to present a demo in a dual-version of your document whilst you know that only the IE-users will have it available.)
In some applications you might need to prepare different versions anyway. So it makes sense to string them together by a doorway page and avoid the dual-version page altogether.

Take for example this very article. Did you notice that it adapted to your browser automatically? Well, try it in any none-IE-browser. It is cross-browser fit!

previous next top

Alternative Link

If you have a great number of documents on your web site, many of them made cross-browser specific by disparate methods, you will have a problem eventually: You need to link from document A (handled by, say, Dual-version Page) to document B (which has Separate Versions).

Which one do you link to? Whatever your visitors' browser, the link might lead to the wrong version. What would be needed now is a link to the _ie version if the current browser is IE, to the _ns version otherwise.

With the tool introduced above you can do that. Instead of a hard-coded link you should code it as follows:

To your visitors it will look just like a normal link. However, when it is clicked, first the browser will be checked. If it is found to be IE, the document given by the first argument ( '…_ie.htm' ) will be linked to. If an NS-browser is found, the current document will be replaced by the second document ( '…_ns.htm' ).

previous next top

Dynamic Creation

If you have a rather complicated document, it will require some seconds of setup time (i.e. time needed to make the document fully available to the readers, once it has been loaded).

If your document is a Dual-version Page, during this time your readers will see the NS-parts. They might try to click on them, expecting to be scrolled there - but nothing happens.

They could perceive that as a turn-off and tend to sidestep your web site henceforth. So it will be better to avoid that in the first place.

A fairly simple method to do that is having the NS-parts dynamically created - at least those at begin of the document.

Normally it will be a sort of SectionMenu that will be atop a HTML document. A typical NS SectionMenu would be a collection of links to bookmarks, such as:

<A HREF="#1">Section 1</A> | <A HREF="#2">Section 2</A> | <A HREF="#3">Section 3</A>

You could have it created dynamically by a function like the following:

function SectionMenu_NS(args)
{
  if(!document.all)	// (to make it NS-specific)
  { var i,arg;
    for (i=0; arg=SectionMenu_NS.arguments[i]; i++)
    {
     if(i>0)  document.writeln(' | ');
     document.write  ('<A HREF="#'+(i+1)+'">'+arg+'</A>');
    }
  }
}

Now you could tell the browser to create it simply by:

<SCRIPT>SectionMenu_NS('Section 1','Section 2','Section 3')</SCRIPT>

If the document is loaded by an IE-browser, it will create no code at all. The readers are not confused by anything that is hidden after some seconds - it was never there!

However, if the document is loaded by an NS-browser, the code of the SectionMenu will be created. The readers will notice no difference to if it had been hard-coded.

previous top

Make your Web SiteCross-Browser Fit

Make your Web Site
Cross-Browser Fit