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:
An outline of the options available for creating
Ways of detecting the different browser makes and
Creating and presenting pages that are complex and
attractive, yet still compatible
Creating Channel links in Internet Explorer and
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
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,
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
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
Share (end 1999)
Share (mid 1998)
Netscape Navigator 2.x
Netscape Navigator 3.x
Netscape Navigator 4.x and 5.x
Internet Explorer 2.x
Internet Explorer 3.x
Internet Explorer 4.x and 5.x
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>
elements), and the standard HTML controls (for example <INPUT>,
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
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
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