Alex Homer's Professional ASP 3.0 Tech

Alex Homer's Professional ASP 3.0 Tech

by Alex Homer

Paperback(2000)

$49.99

Product Details

ISBN-13: 9781861003218
Publisher: Apress
Publication date: 02/01/2000
Edition description: 2000
Pages: 896
Product dimensions: (w) x (h) x 0.07(d)

Read an Excerpt

Chapter Four

This manuscript is an abridged version of a chapter from the Wrox Press book Alex Homer's Professional ASP Web Techniques. One of the main thorns in the side of all Web developers has to be that of browser compatibility. Chapter 4 is, therefore, devoted to the issues involved in trying to offer the best cross-platform support for browsers, coving issues such as detecting the different browser makes and versions, creating and presenting pages that are complex and attractive, yet still compatible, and creating Channel links in Internet Explorer and Netscape Navigator.

Alex Homer's Professional ASP Web Techniques builds upon the successful formula of Professional ASP Techniques for Webmasters - 1861001797, but this time reaching much more deeply into present day technology choices and troubleshooting, discussing only those events that a real webmaster in the field can solve with code and architectural changes. For further details about the book, and other books in our range, visit the Wrox Press Web Site.

  • Managing Browser Compatibility
  • Detecting the Browser Version Part 1
  • Detecting the Browser Version Part 2
  • Compatible and Browser-Specific Pages
  • Creating Browser-Specific Pages
  • Channels in IE and Navigator
  • Summary


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 browser-compatible sites

  • Ways of detecting the different browser makes and versions

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

  • 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:

Browser

Share (end 1999)

Share (mid 1998)

Netscape Navigator 2.x

2 %

2 %

Netscape Navigator 3.x

3 %

12 %

Netscape Navigator 4.x and 5.x

35 %

38 %

Internet Explorer 2.x

2 %

2 %

Internet Explorer 3.x

2 %

10 %

Internet Explorer 4.x and 5.x

46 %

30 %

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:

...

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.


Detecting The Browser Version

Having looked at the kinds of features we might decide to support or to avoid, we'll consider the other half of the equation. How do we know which browser we're dealing with when we do get a visitor? If we decide to build pages that are specially tailored for particular browsers, we need to be able to identify the browser when it hits our site with a request for a page.

This can be done in several ways, and you've seen some examples of the techniques in earlier chapters. We'll summarize them here, then explore how ASP can make the job a whole lot easier. In the next chapter, we'll be creating a version of our simple frameset site (first seen in Chapter 2) that automatically provides a different set of more advanced features to each suitably equipped browser.

Summary Of Browser Detection Techniques

We can detect which browser we are dealing with on the client itself using scripting, or on the server with either scripting or a special Active Server component. We'll start with the client-side techniques. These allow us to detect the version, and hence the capabilities of the browser, inside a page that we provide.

Browser Detection With Client-Side Script

All browsers that support scripting also provide a standard set of objects as part of their Document Object Model (DOM). In fact, this is a bit of a misnomer, because the objects also provide information about the browser itself, and not just the document (or page) it is displaying. The object we're interested in is the navigator object - probably named as such because the first browsers were often referred to as 'navigators', and Netscape adopted this as their product name.

The navigator object, a sub-object of the main top-level window object, provides the three useful properties userAgent, appName and appVersion. The userAgent property contains the string that completely identifies the browser, and is sent to the server in the HTTP headers with each page request it makes. The appName and appVersion properties are available only in client-side script, and contain the manufacturer's name and the browser version in a more readable format.

Reading The Navigator Object Properties

The following code, which is included in the samples available from our Web site at http://www.wrox.com/, writes the values of the three properties into the page using client-side script when you load it. It also provides some information about your chosen browser, by analyzing the property values. We've highlighted the script code to make it easier to see what's going on:

<HTML>

<HEAD><TITLE>Detecting the browser type</TITLE></HEAD>

<BODY>

<H3>Details of your browser</H3>

<TABLE>

<TR>

<TD ALIGN="RIGHT">navigator.userAgent:</TD>

<TD><B>

<SCRIPT LANGUAGE="JavaScript">

<!—

document.write(navigator.userAgent)

//—>

</SCRIPT></B>

</TD>

</TR>

<TR>

<TD ALIGN="RIGHT">navigator.appName:</TD>

<TD><B>

<SCRIPT LANGUAGE="JavaScript">

<!—

document.write(navigator.appName)

//—>

</SCRIPT></B>

</TD>

</TR>

<TR>

<TD ALIGN="RIGHT">navigator.appVersion:</TD>

<TD><B>

<SCRIPT LANGUAGE="JavaScript">

<!—

document.write(navigator.appVersion)

//—>

</SCRIPT></B>

</TD>

</TR>

</TABLE><P>

<SCRIPT LANGUAGE="JavaScript">

<!—

if (navigator.appName.indexOf('Netscape') != -1) {

document.write('To upgrade your browser go to ' +

'<A HREF="http://home.netscape.com/download/">' +

'http://home.netscape.com/download/<\/A><\/P>');

if (navigator.appVersion.substr(0, 1) > 3)

document.write('You can use Netscape Dynamic HTML');

}

if (navigator.appName.indexOf('Microsoft') != -1) {

document.write('To upgrade your browser go to ' +

'<A HREF="http://www.microsoft.com/ie/">' +

'http://www.microsoft.com/ie/<\/A><\/P>');

if (navigator.appVersion.substr(0, 1) > 3)

document.write('You can use Microsoft Dynamic HTML');

}

//—>

</SCRIPT>

<NOSCRIPT>

Sorry, your browser doesn't support client-side scripting,

so it can't display the details about your browser.

</NOSCRIPT>

</BODY>

</HTML>

Note that, where we have closing HTML tags, we include a backslash character in the string we write to the document. For example, '..<\/A><\/P>'. According to the W3C standards, a combination of a forward slash character followed immediately by an alphabetic character indicates the end of a <SCRIPT> section. So, if we are trying to write any closing HTML tags with document.write, we must declare at least part of the 'illegal' combination within the string as being a character literal. In JavaScript we can do this with a backslash, here placed before the forward slash. In VBScript, we usually replace the forward slash with Chr(47). However, most browsers don't follow the W3C rule, and will only accept </SCRIPT> as a closing script tag. But it's wise to play safe...

Here are the results with Internet Explorer 5.0 and Navigator 4.61:

...

Note that IE5 returns '4.0' as the version number at the start of the appVersion property, because this is the version of Mozilla that it is compatible with. To get the actual IE version number, we need to parse the string for the version number after the 'MSIE' product identifier.

...

So, we can quite easily detect the browser type using script running in the page on the client. We'll see how we might use this later on. However, it's not always as straightforward as you might imagine. For example, here's what the page looks like when you open it in Opera 3.6:

...

Whoops, a wrong hyperlink for the upgrade. But whose fault is this? Look at the value of the navigator.appName property - 'Netscape'!

Server-Side With ASP

Obviously we can only use client-side script when the browser supports this. If you look back at the end of the code we used earlier, you'll see that we tried to trap this problem using a <NOSCRIPT> section, which contains a note to the viewer explaining why they can't see any browser details. An easy way to prevent this occurring is to do the work on the server instead of on the client. There are two basic ways of achieving this, either by analyzing the HTTP USER-AGENT value sent from the browser, or with a special component that can do the hard work for us.

Using The HTTP USER-AGENT Value

When we get a page request from a browser or user agent, it should provide a value for the USER-AGENT string within the HTTP headers. We saw this when we looked at the contents of the Request.ServerVariables collection in Chapter 2. We can quite easily look at the string, and decide the browser type. The ASP code below does just that, and provides a similar result with Internet Explorer and Navigator as our previous client-side page (we can't get at the appName and appVersion properties, which are only available to script running on the browser, so these are omitted):

<%@ LANGUAGE=VBSCRIPT %>

<% strUA = Request.ServerVariables("HTTP_USER_AGENT") %>

...

<TABLE>

<TR>

<TD ALIGN="RIGHT">navigator.userAgent:</TD>

<TD><B><% = strUA %></B>

</TD>

</TR>

</TABLE>

<P>

<%

QUOT = Chr(34)

If InStr(strUA, "MSIE") Then 'it's a Microsoft Browser

Response.Write "To upgrade your browser go to " _

& "<A HREF=" & QUOT & "http://www.microsoft.com/ie/" _

& QUOT & ">http://www.microsoft.com/ie/</A></P>"

intVersion = CInt(Mid(strUA, InStr(strUA, "MSIE") + 5, 1))

If intVersion > 3 Then

Response.Write "You can use Microsoft Dynamic HTML"

End If

Else

If InStr(strUA, "Mozilla") Then 'it's a Netscape-compatible browser

If InStr(strUA, "compatible;") = 0 _

And InStr(strUA, "Opera") = 0 Then 'it's probably a Netscape browser

Response.Write "Your browser is probably Navigator. You can " _

& "download the latest verion of Navigator from " _

& "<A HREF=" & QUOT & "http://home.netscape.com/download/" _

& QUOT & ">http://home.netscape.com/download/</A></P>"

intVersion = CInt(Mid(strUA, InStr(strUA, "/") + 1, 1))

If intVersion > 3 Then

Response.Write "You can probably use Netscape Dynamic HTML"

End If

Else 'not Netscape, so we'll allow the user to search on the Web for it

If InStr(strUA, "Opera") Then

'Opera 3.60 doesn't include 'compatible' in UA string

strProduct = Trim(Mid(strUA, InStr(strUA, ")") + 1))

Else

'use the part after the 'compatible;' keyword

strProduct = Mid(strUA, Instr(strUA, "compatible;") + 11)

strProduct = Trim(Left(strProduct, Instr(strProduct, ";") - 1))

End If

strSearchURL = "http://www.altavista.digital.com/cgi-bin/query?q=" _

& Server.URLEncode(strProduct & " web browser")

Response.Write "Your browser is Navigator-compatible. You can " _

& "search for the manufacturer using a search engine, such as " _

& "<A HREF=" & QUOT & strSearchURL & QUOT & ">" & strSearchURL _

& "</A></P>"

End If

End If

End If

%>

...

...

Table of Contents

Chapter 1 - Dynamic Web Sites - The Foundations
Chapter 2 - Managing Navigation
Chapter 3 - Building Pages Dynamically
Chapter 4 - Managing Browser Compatibility
Chapter 5 - A Compatible Frameset Example
Chapter 6 - Access Control and Premium Content
Chapter 7 - Remote Administration Of Your Site
Chapter 8 - Feedback, Errors, and Broken Links
Chapter 9 - Gathering Information About Your Visitors
Chapter 10 - Creating Reports About Your Visitors
Chapter 11 - The 'Plug and Play' Chapter
Chapter 12 - Integrating Email With Your Web Site
Chapter 13 - Integrating XML With Your Web Site
Chapter 14 - The Blue-Sky Chapter

Appendices
A - Certificates And Certificate Services
B - ASP Component And Resource Sites
C - ASP Object Model Reference
D - Scripting Library Objects Reference
E - ASP 3.0 Installable Components Reference
F - ActiveX Data Objects 2.5 Reference
G - HTTP 1.1 Header Codes
H - Language Codes And LCID Values
I - Color Names And Values
J - HTML Character Entities Equivalents
K - Server-Side Include Directives And Utilities
L - MIME Types And File Extensions
M - Glossary Of Terms And Acronyms
N - Errata And Support

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews