This article provides an overview of each browser's approach to DHTML. It also explores some strategies that you might use for DHTML applications that must run identically on Navigator and Internet Explorer.

What Is a Platform?

The term platform has multiple meanings in web application circles, depending on how you slice the computing world. Typically, a platform denotes any hardware and/or software system that forms the basis for further product development.

Operating system developers regard each microprocessor family as a platform (Pentium, PowerPC, or SPARC CPUs, for example); desktop computer application developers treat the operating system as the platform (Win16, Windows 95/NT, MacOS8, Unix, Linux, and the rest); peripherals makers perceive a combination of hardware and operating system as the platform (for example, a Wintel machine or a Macintosh).

The de facto acceptance of the web protocols, such as HTTP, means that a web application developer doesn't have to worry about the underlying network transport protocols that are being used. Theoretically, all client computers equipped with browsers that support the web protocols-regardless of the operating system or CPU-should be treated as a single platform. The real world, however, doesn't work that way.

Today's crop of web browsers are far more than data readers. Each one includes a highly customized content rendering engine, a scripting language interpreter, a link to a custom Java virtual machine, security access mechanisms, and connections to related software modules. The instant you decide to author content that will be displayed in a web browser, you must concern yourself with the capabilities built into each browser. Despite a certain level of interoperability due to industry-wide standards, you must treat each major browser brand as a distinct development platform. Writing content to the scripting API or HTML tags known to be supported by one browser does not guarantee support in the other browser.

If you are creating content, you must also be aware of differences in the way each browser has been tailored to each operating system. For example, even though the HTML code for embedding a clickable button inside a form is the same for both Navigator and Internet Explorer, the look of that button is vastly different when rendered in Windows, Macintosh, and Unix versions of either browser. That's because the browser makers have appropriately observed the traditions of the user interface look and feel for each operating system. Thus, a form whose elements are neatly laid out to fit inside a window or frame of a fixed size in Windows may be aligned in a completely unacceptable way when displayed in the same browser on a Macintosh or a Unix system.

Even though much of the discussion in this book uses "cross-platform" to mean compatible with both Netscape and Microsoft browsers ("cross-browser" some might call it), you must also be mindful of operating-system-specific details. Even the precise positioning capabilities of "cross-platform" cascading style sheets do not eliminate the operating-system-specific vagaries of form elements and font rendering. If you are developing DHTML applications, you can eliminate pre-version 4 browsers from your testing matrix, but there are still a number of browser and operating system combinations that you need to test.

Navigator 4 DHTML

As early as Navigator 2, JavaScript offered the possibility of altering the content being delivered to a browser as a page loaded. It was Navigator 3, however, that showed the first glimpse of what Dynamic HTML could be. This browser implemented the IMG HTML element as a document object whose SRC attribute could be changed on the fly to load an entirely different image file into the space reserved by the <IMG> tag.

In DHTML parlance, this is known as a replaced element because it is rendered as an inline element (capable of flowing in the middle of a text line), yet its content can be replaced afterward. The most common application of this replacement feature is the mouse rollover, in which an image is replaced by a highlighted version of that image whenever the user positions the cursor atop the image. If you surround the <IMG> tag with a link (<A>) tag, you can use the link's mouse event handlers to set the image object's source file when the cursor rolls atop the image and when it rolls away from the image:

<A HREF="someURL.html" 
    onMouseOver="document.images['logo'].src = 
        'images/logoHOT.jpg'" 
    onMouseOut="document.images['logo'].src = 
        'images/logoNORMAL.jpg'">
<IMG NAME="logo" SRC="images/logoNORMAL.jpg" 
        HEIGHT=40 WIDTH=80>
</A>

A glaring limitation of this scheme, however, hindered some designs. The size of the image area was fixed by the IMG element's HEIGHT and WIDTH attributes when the page loaded. All other images assigned to that object had to be the same size or risk being scaled to fit. While rarely a problem for mouse rollovers, the lack of size flexibility got in the way of more grandiose plans.

more ...

Despite a certain level of interoperability due to industry-wide standards, you must treat each major browser brand as a distinct development platform. Writing content to the scripting API or HTML tags known to be supported by one browser does not guarantee support in the other browser.