c-- styles for logos and headline links do not modify internet, red, or black styles -->
|
|
|
|
|
|
A DOM for all Seasons The culprit in this divide is the Document Object Model. Dynamic HTML is an object-oriented organism and, as such, the DOM is its anatomy. As its name implies, the DOM defines the building-block objects which make up a Web page, and the various characteristic properties which belong to each of those objects. Interacting with these building blocks, such as modifying an object's properties or triggering a behavior as a result of an action at an object, is therefore defined by the Document Object Model. And, wouldn't you know it, Netscape version 4 and Microsoft versions 4 and 5 have thus far adopted different DOM's to integrate into their respective browsers. There may or may not be promise on the horizon: the long awaited Netscape 6 (there was no version 5) is alleged to fully support the Word Wide Web Consortium's standards for the DOM Level, CSS Level 1 and much of Level 2. Should Netscape 6 gain market share, its standard compliance could pave a new way for cross-browser compatible coding -- however, it remains quite unclear at this point whether Netscape 6 will be able to beat back Microsoft's large share of the browser market. Both DOM's share many similar qualities, and even many compatible objects. Both are, after all, reaching towards the same goals -- manipulating the components of a Web page. Even among similar objects, though, there are sometimes subtle differences which result in different behaviors depending upon the browser being used. More troubling, though, are the many major objects which reside in only one DOM or the other; sometimes there is a similar, homologous object in the the opposing DOM: consider Netscape's layer object, whose properties are mostly mimicked in Microsoft's style object. In other cases, one DOM possess an object without equal in its competitor: Microsoft's IFRAME object represents an in-line floating frame, a feature which Netscape does not support. It gets worse -- Microsoft's DOM can access nested layers, where one layer resides "within" a containing layer, while Netscape's DOM won't see nested layers at all. Oy! The upshot of all this heartache is that you, the cross-browser developer, face three potential obstacles, listed in order of increasing mental anguish: 1. Features which can be implemented in either browser, but require different syntaxes; 2. Features which can be implemented in either browser, but using different approaches; 3. Features which can only be implemented in only one browser, with an alternate design for the other. Aside from sheer ingenuity, which this article cannot teach, we will look at methods for addressing each of the above three scenarios. A Spork in the Road When considering cross-browser code you must first decide on a main approach: do you fork the code into two independent versions, one for each browser; or, do you write a single version of code which internally adapts to the browser being used -- sort of a hybrid code, not unlike the high-school cafeteria's plastic spork. Although some developers strongly suggest that the spork approach is the most elegant solution, in truth there are pros and cons to both schemas. The basic idea behind forking the code is quite simple. You could simply create two wholly independent DHTML pages, one of which is tuned for Internet Explorer and the other for Netscape. Visitors to your site would connect directly to neither page; instead, they would connect to a "forking page," which detects their browser and forwards them to the appropriate version. An example forking page appears below -- it simply uses JavaScript to evaluate the situation. The primary advantage to this approach is that it is simple to implement, assuming you have no troubles writing your DHTML in two versions, one for each browser. The disadvantages to top-level forking are several, notably you must maintain and update two versions of the page content and bookmarks made by the user will incorrectly point to the browser-specific page rather than the forking page.
<html><head>
<title>MySite Browser Detect</title>
<script language="JavaScript">
<!--
function version()
{ if ((window.navigator.appName.indexOf("Netscape")==0) &
|
|