Dynamic HTML: The Definitive Reference

Document Object Model

When an HTML page loads into a scriptable browser, the browser creates a hidden, internal roadmap of all the elements it recognizes as scriptable objects. This roadmap is hierarchical in nature, with the most “global” object—the browser window or frame—containing a document, which, in turn, contains a form, which, in turn, contains form elements. For a script to communicate with one of these objects, it must know the path through the hierarchy to reach the object, so it can call one of its methods or set one of its property values. Document objects are the “things” that scripts work with.

Without question, the most hotly contested competition between Navigator and Internet Explorer has been how each browser builds its internal roadmap of objects. This roadmap is called a document object model (DOM). When one browser implements an object as scriptable but the other doesn’t, it drives scripters and page authors to distraction. A lot of authors felt the sting of this problem when they implemented image-swapping mouse rollovers in Navigator 3. They soon discovered that images were not scriptable objects in Internet Explorer 3, so their IE 3 users were getting script errors when visiting the sites and moving their mice across the hot images.

In an effort to standardize this area, a separate working group of the W3C is charged with setting recommendations for an HTML Document Object Model (www.w3c.org/DOM/) that would become the common denominator among browsers (the HTML subgroup is only one branch of a larger DOM effort). This is an incredibly difficult task for a number of reasons: Netscape and Microsoft are often at loggerheads on DOM philosophy; technically the browsers aren’t built the same way inside, making common implementation of some ideas difficult; and historically authors are familiar with their favorite browser’s way of handling objects and don’t want to learn an entirely new method.

Of all the standards discussed in this chapter, DOM is the least solid. From indications in the working drafts, even the first release won’t cover some important categories, such as event handling. The issues around incompatible DOMs involve a long, uphill struggle that DHTML authors will face for a while. We will be tantalized by features of one browser, only to have our hopes dashed when we learn that those features aren’t available in the other browser.

By virtue of being the first scriptable browser on the market by quite a margin, Navigator 2 was the first to incorporate a scriptable object model. A subset of HTML elements were exposed to scripts, but once a document was loaded into a window or frame, nothing outside of form control content (i.e., text in text entry areas, selections in checkboxes, etc.) could really change without reloading the window or dynamically writing an entirely new document to the window. Even in Navigator 3, the image was the only truly dynamic HTML element in a document (as shown in those mouse rollovers).

Internet Explorer 3, as few web authors seemed to realize, was based on the scriptability of Navigator 2. That’s why the image object didn’t exist in IE 3. Most authors had left Navigator 2 in the dust of history, when, in fact, they should have kept its limited capabilities fresher in their minds, to accommodate IE 3.

In the Version 4 browsers, however, the object model advantage has shifted dramatically in Microsoft’s favor. Literally every HTML element is exposed as a scriptable object in IE 4, and you can modify the content and style of inline content (not just positionable elements) on the fly. IE 4 automatically reflows the page (and quickly, I might add) whenever you do anything that changes the page, like adjusting the size of a font for a phrase in a paragraph or inserting some HTML text in the middle of a paragraph.

Navigator 4, on the other hand, adds little to dynamic scripting beyond the ability to swap the content of layers. Elements are exposed to scripts, but only in script statements that use JavaScript to set style sheet rules as the page loads. And even if the object model allowed content modification on the fly, pages do not automatically reflow in Navigator 4.

The working draft of the DOM recommendation includes specifications that are somewhere between the functionality provided by IE 4 and that provided by Navigator 4. The draft recognizes that most elements should be reflected as document objects whose properties and methods are accessible via scripting. It does not, however, go so far as to dictate the automatic reflow of the page when content changes. That loophole might take some of the pressure off Netscape for implementing this functionality, but it also ensures that page authors are going to have to struggle with the object model disparity for a lot longer (unless you are fortunate enough to be able to design for just one browser).

Chapter 5, and Chapter 6, cover the current DOM implementations, while Chapter 9, provides a complete DOM reference.