Managing Browser Compatibility

Having seen how easy it is to create dynamic content, we now need to move on to a major thorn in the side of all Web developers – browser compatibility. It's sometimes hard to believe that the situation has become as difficult as it has when we have a 'ruling body' in the shape of the World Wide Web Consortium (W3C) setting standards for HTML, scripting language support, page layout styles, and so on.

The problem is that the rate of change of the technology outstrips any democratic process – even in the case of the W3C, whose decision-making process is swift compared to those in most other industries. As fast as one version of HTML is fixed as a standard, there are new browsers available that support new effects, new HTML elements, and even new concepts of how the Web is used. A perfect example is the so-called 'push' technology, which browser manufacturers have implemented as 'Channels'. There are several incompatible systems available, and many are more 'pull' than 'push'.

All this means you have to start making choices. Which browsers do you support? Which do you disregard? And how do you provide 'fallback' for older and less capable browsers? In Chapters 9 and 10 of this book you'll see how we can measure the proportion of traffic that our site gets from each browser type. Of course it may be that you get more hits from one browser because your site doesn't support the other browser types. If your pages don't work in Netscape Navigator 4, you won't get a lot of repeat visits from Navigator 4 users...

So, this chapter is devoted to the issues involved in trying to offer the best cross-platform support for browsers. We'll look at:

q         An outline of the options available for creating browser-compatible sites

q         Ways of detecting the different browser makes and versions

q         Creating and presenting pages that are complex and attractive, yet still compatible

q         Creating Channel links in Internet Explorer and Netscape Navigator

We'll begin with a look at the different issues involved in compatibility, and outline the solutions available.

Creating Browser-Compatible Sites

The first and most obvious question you should be asking yourself when you build HTML pages is what level of features do you intend to incorporate into them? If you have a particular task to achieve in a page, what's the best way to go about it?

When you build a Windows 32-bit application with a programming language like Visual Basic or C++, you generally don't worry about which particular version of the operating system your user has (Windows 95, Windows 98, Windows NT or Windows 2000), or what other software they may have installed. You just get on and design the interface and the underlying working parts, stitch it all together, and compile it.

Of course, creating Web pages has become easier as more and more tools have become available. At the same time, however, we keep changing the target browsers that these tools are aimed at. As fast as one of the Web design programs gets onto the market, there's a new browser available with features that are not supported. The goalposts just keep moving. You have to feel sorry for the people who build these tools (except for Microsoft who  make one of the two mainline browsers – it's partly their fault).

Which Browser Do I Target?

The end result is that, to at least some extent, you need to consider which browsers you intend to support when you build Web pages. You can build a site that is 'designed for Netscape Navigator' or 'best viewed with Internet Explorer', but this may not be the best way to maximize your site's potential. Besides, if you're using the site to try and sell things, telling a visitor that they've got the wrong browser isn't the best way to start.

The ultimate aim is to design pages that are as widely compatible as possible. This doesn't mean, however, that we can't take advantage of the features that the newer browsers support. We just need to make sure that our pages fallback properly, or 'fail gracefully' – especially to provide support for older browsers that aren't able to incorporate our more advanced techniques. Fallback is generally accepted to mean that our pages will use the closest available features of the browser to provide an equivalent (but possibly degraded) performance, yet still remain usable.

Other Types Of User Agent

It's very easy to forget that the browser we use every day isn't the only kind of user agent that is in use on the Web. The term 'user agent' was coined to reinforce this fact, because our site may be visited by a host of applications that are not browsers in any real sense of the word. Included in this are the delightfully named crawlers, robots and spiders. These terms describe applications and 'intelligent agents', which roam the Web following links, creating the indexes for search engines, or downloading and caching pages for offline viewing. These will expect our pages to include various kinds of elements that identify them, such as <META> tags. We'll look at this whole issue in more detail in Chapter 8

However, there is also a second category of user agent, more like a browser in nature, which we should make every effort to support. Visitors who suffer from physical disabilities often use special user agents that can magnify parts of your pages, or even convert them into spoken text. Simply making sure that you always provide text equivalents for graphics and links in your pages makes all the difference to these visitors – make a point of including the ALT and/or TITLE attributes in your code wherever you can.

Browser Market Shares

In Chapter 2 we discussed the reasons why you might decide to use or avoid HTML frames on your site. This kind of decision will be required for many other features as well. For example, do you use client-side VBScript and ActiveX controls, or JavaScript and Java applets? What about the decision to use a <STYLE> definition section instead of <FONT> tags? More to the point, what about the different varieties of Dynamic HTML?

You might make decisions based on your favorite environment and your own choice of browser. However, this is not the best approach in a commercial situation, or even where you're just aiming for maximum compatibility. Instead, you need to base the decision on the number of browsers that will and will not be able to display your pages properly. So how do you find out which browsers people are using?

The Industry Source - Browser Watch

Probably the best-known source of browser market share statistics is Browser Watch (http://browserwatch.internet.com/). This is a service provided by Dave Garaffa for Internet.com – a division of the Mecklermedia Corporation that provides Internet news and resources. Mecklermedia's site gets thousands of hits every day, and records each visitor's browser version using the USER-AGENT string sent in the HTTP header (we met this in Chapter 2):

Using the statistics available from Browser Watch, combined with those from half a dozen other sites (including our own) we put together this breakdown of the approximate percentage of browsers from the two main manufacturers at the end of 1999. We also show the figures from mid 1998 for comparison:

Bear in mind that this is based mainly on the number of hits on the Browser Watch-monitored pages, and is by no means the same for all sites. For example, the Wrox Web-Developer site has a far higher percentage of visitors using Internet Explorer (around 70%), while various academic institutions (which are often heavily Unix based) provide statistics showing that anything up to 90% of hits to their sites are from Netscape browsers. Recent independent industry reports put the overall market shares at 50% Internet Explorer and 45% Navigator.

The Two Main Browser Types

As around 90% of users appear to be using browsers from one of the two main manufacturers, Microsoft and Netscape, we'll concentrate our discussions on these two. However, remember the other browsers and non-browser user agents we mentioned earlier: while we're probably unlikely to create pages aimed solely at, say, the Lynx, Cyberdog or Opera browsers, it doesn't mean that we should ignore fallback features. You'll see more of this later in the chapter. What we'll do next is break down the various browser features into broad categories, so that you can decide what features to support.

Choosing Broad Feature Levels

As browsers tend to be backwards compatible (although not necessarily in all features), we can generally assume that features supported in older browsers will continue to work on newer versions from the same manufacturer. With this in mind, we can choose broad feature categories and measure the approximate likely percentage of all visitors' browsers (or user agents) that will support each category.

This table shows eleven categories for Netscape Navigator and Internet Explorer, ranging from simple basic HTML to the specific features in the latest versions. Because some 5% of visits are from robots or spiders that simply extract <META> information and index the page, we have adjusted the totals to reflect the approximate percentage of interactive visitors (that is, people that are surfing your site with a browser). It's encouraging to see that the overall percentage of browsers that support 'high-level' features is increasing:

* Note that the Internet Explorer and Netscape Navigator versions of Dynamic HTML are not compatible with each other. The two Percentage figures represent the level of support for each browser, with IE 4 being the first and Navigator the second in each case.

If you're wondering why only 95% of browsers seem to support basic HTML, remember that some will be the crawlers, robots, spiders and other user agents we mentioned earlier. In reality, despite the statistics, you would probably find that the percentage supporting basic HTML and HTML controls is close to 100%. Besides, if we don't use this to create our most basic pages, what are we going to use? And, if you answered XML to the last question, go to the top of the class. Extensible Markup Language is an HTML-style language designed to provide more flexibility in creating all kinds of documents – not just Web pages. We'll be looking at how we can use XML later in the book.

So, if we just use the features from HTML Tables downwards, we can expect almost all visitors to be able to view our pages. This includes direct text formatting (for example the <FONT> and <BASEFONT> elements), and the standard HTML controls (for example <INPUT>, <SELECT>, and so on). As we move up the feature list, the overall proportion of browsers that won't be able to fully render the pages increases. The interesting point is that it stays at over 90% right up to the inclusion of client-side JavaScript, as well as Java applets and frames. So it looks like our earlier decision to go with frames on our example site was a good one.

The big drop comes when you introduce ActiveX controls or VBScript (the two tend to go together). In fact, from this point upwards, you are really forced to decide which individual browser to support. In particular, the non-compatible versions of Dynamic HTML make it necessary to consider different versions of each page if you need to maintain cross-browser compatibility at this level. This is something we'll be looking at in a lot more detail later on in this chapter.

Individual Feature Level Compatibility

While we assume that we can still support most of our visitors when using frames, and support around three-quarters of them when using <STYLE> elements, you should be aware that there are lower-level compatibility problems still lurking. For example, with the <STYLE> element, we find that each of the three browsers (IE3, IE4/5 and Navigator 4/5) supports a different set of individual style properties, and, when using a <FRAMESET> element, the FRAMESPACING attribute is only supported in IE3 and above. However, IE3 doesn't support the BORDERCOLOR attribute, which Navigator does. In general, though, your page is likely to still work in much the same way on all browsers that support a feature like frames or styles, even though the attribute or property sets may differ.

The World Wide Web Consortium (W3C) at http://www.w3.org/ publishes documentation that defines the HTML language standards, but not the support in individual browsers. The Wrox Press book Instant HTML Programmers Reference (ISBN 1-861001-56-8) aims to resolve this deficiency by listing all the elements and attributes for the three most recent HTML standards, and the three most recent versions of Internet Explorer and Netscape Navigator.

Contents | Next