The Document Object Model Dissected

1. Introduction 2. Gray's Anatomy\ Master of Your DOM 3. Use the DOM, Luke 4. Netscape: The DOM
5. Microsoft: DOM, the Sequel

6. DOM of the Future Introduction Developing successful web pages these days involves more than simply pumping out HTML tags. Ever-evolving towards a true development environment, complex web pages now grow out of a coalition of technologies, including Cascading Style Sheets, JavaScript (both loosely referred to as "Dynamic HTML"), and possibly even XML. Consequently, web pages are complex organisms, far more advanced than their protozoan ancestors. Working with such an organism requires a thorough insight into its anatomy, and that is the basis and purpose for the Document Object Model. In this discussion we'll look closely at the "DOM," as it is known -- what it is, how you use it, and where it might be leading us. The DOM is a Web programmer's ally, but as such, we must assume some Web programming experience. This article is not a tutorial on JavaScript syntax or Dynamic HTML; however, if you have developed in either of the above to even a small extent, you will certainly be interested in understanding the DOM, even if you haven't heard of it until now.

Gray's Anatomy The classic biology text, a cornerstone reference for students of the human composition, sets out to detail the components, which make up the human organism; form and function. This Cartesian approach assumes that if we understand the characteristic properties of each building block we can understand the whole. More specifically, if we know how to modify (fix, improve, etc.) the components, we can modify the whole in a targeted way. Quite similarly, the Document Object Model sets out to map the Web page for developers, as Gray's Anatomy maps the body for doctors. Broken down into its own components, the DOM details the characteristic properties of each element of a Web page, thereby detailing how we might manipulate these components and, in turn, manipulate the page. There is an important difference between the two references, however: while Gray's Anatomy is a descriptive source, subject to the design implemented by Nature, the Document Object Model is prescriptive, as it defines what components we may or may not modify, and how, as decided by a panel of developers. The crux of this difference is that, unlike the components of the human body, the inventory of components which make up a web page are rather arbitrarily defined. Simply put, one panel of developers may decide to break the Web page down into a certain Set X of components while another panel may prefer to reduce a page into Set Y of components. So, while Gray's Anatomy speaks usefully to all human bodies, a particular DOM speaks only for web pages within a supporting browser.

Microsoft's DOM, as implemented through their fifth generate browser (MSIE 5.x) is not fully compatible their with Netscape's generation DOM, as implemented through fourth browser

(Navigator/Communitor 4.x). What's more, the World Wide Web Consortium (W3C) -- recognized standards body of the web -- has been brewing their own DOM, having released their "DOM Level 1" and on the verge of releasing their "DOM Level 2" specifications. The theory is that browser developers should support the W3C standard, eliminating incompatibility. Netscape's recent preview of their fifth generation browser (named version 6 for marketing reasons) features a DOM extremely compliant with W3C standards, but not necessarily compliant with Microsoft's DOM. This discord, an ongoing challenge to web developers, will likely persist.

Master of your DOM The inconsistencies between browsers and their supported Document Object Models have been the cause of developers' cramps, night sweats, and eating disorders -- not to mention lost productivity time and increased costs for clients. But there is an up-side: needing to know two DOM's may inspire you to become a DOM master, learning the DOM's intimately. This is a Good Thing, because mastery of a DOM is the key to great Web page development, even if the two corporate giants reconcile their differences. Before we delve into either DOM in specific, let's consider the composition of the DOM itself -- in other words, the anatomy of an anatomy!

Both Netscape and Microsoft Document Object Models break down Web pages into roughly four types of components, summarized in the table below.

Component Makeup of the Document Object Model. Component Description Container which reflects a particular element of a page; objects "contain" the various characteristics which Objects apply to that element (known as properties and methods); in a form. Characteristics of an object; for example, the document object possesses a bgColor property which reflects the background color of the page. Using a programming language (e.g. JavaScript) you may, via Properties this property, read or modify the color of the current page. Some objects contain very many properties, some contain very few. Some properties are read-only while others can be modified, possibly resulting in immediate on-screen results. Methods A method typically executes an action which somehow acts upon the the object by which it is owned. Sometimes the method also returns a result value. Methods are triggered by the programming language being used, such as JavaScript. For example, the window object possesses a method named alert(). When supplied with string data, the alert() method example: the submit object contains properties and methods relevant to the submit button

causes a window to pop up on the screen containing the data as its message; e.g. alert("Invalid entry!"). An event is used to trap actions related to its owning object; typically, these actions are caused by the user. For example, when the user clicks on a submit button, Events this is a click event which occurs at the submit object. By virtue of submitting a form, a submit event is also generated, following the click event. Although these events occur transparently, you can choose to intercept them and trigger specified program code to execute. Since it seems that both DOM's outline the same types of page components, how do these two DOM's differ? By and large, the differences are in the details. One DOM may contain objects which the other does not; one DOM may support unique properties for an object which itself is common to both; one DOM may support events occurring at an object which are not supported in the other. In fact, at first glance both Microsoft and Netscape's DOM's appear similar -- and they are. Both, after all, are reaching towards a similar goal -- to reduce the anatomy of the page into manipulability parts. Use the DOM, Luke Client-side manipulation of a web page requires some additional programming, beyond HTML (which itself is not programming at all). The Document Object Model serves to "expose" the page to a programming language for the purposes of manipulation. Typically, JavaScript is the programming language of choice for most client-side manipulations, mainly because both major browsers support it. Using JavaScript to manipulate a page through the Document Object Model

is commonly called "DHTML" or "Dynamic HTML". It's important, though, to understand that the Document Object Model is not a "part" of JavaScript. The DOM stands alone, able to be interfaced with any programming language designed to do so -- JavaScript is simply the most popular, although VBScript can also manipulate a page via the DOM within Microsoft's browser. Mastery of the DOM does not equate to memorizing it. Rather, if you understand how the DOM is structured and how to understand its references you can easily turn to a suitable reference for details whenever the need arises. Still, a working knowledge of DOM details -- inevitable after working with it several times -- helps you efficiently sketch out program approaches to achieving a certain goal. Let's begin using the DOM with a close-up look at Netscape's Document Object Model. Netscape: The DOM Despite the recent preview release of Netscape 6, with its support for W3C DOM Level 1 and partial Level 2 standards, we here will focus on the Netscape DOM that has resided within their version 4 browsers for the past couple of years. It will be some time until Netscape 6 proliferates, and although its new DOM poses exciting possibilities, the installed base of Netscape 4.x warrants our attention. It is generally accurate to suggest that Netscape's Document Object Model "begins" at the window object; all other DOM objects being children of the window object. The notable exception to this is the navigator object, whose properties provide information about the browser version, and who is a peer

object of window rather than a child. Netscape provides a reasonable graphical overview of their DOM found in the image below. This image links to the Netscape reference page from which it has been mirrored. An overview of the Netscape 4.x Document Object Model.

Netscape does not publish a single DOM-specific reference document; rather, we must currently work with two documents to learn the Netscape DOM. Unfortunately, Netscape has chosen to dedicate an entirely

separate

document

"Dynamic

HTML

in

Netscape

Communicator" - to coverage of DOM objects which support layers and style sheets, which we should also consider part of the DOM reference Of course, if all this scattered documentation too fragmented to comprehend cohesively, a visit to your friendly book retailer should offer plenty of professionally-authored alternatives -- most such books will come under titles related to "Dyanmic HTML". Once you know where to look for DOM reference half the battle is won. Reading the DOM itself is not terribly difficult, assuming you already understand the meanings such as of objects, properties, for methods, and events, and understand how to use them with a programming language JavaScript. Perhaps, example, you remember that the Netscape DOM provides a text object, which reflects a single-line text input form field. However, you don't exactly know what properties or method this object supports. So, we open a browser to the aforementioned Form Object in Netscape's JavaScript Reference, which presents us with a table of supported form-related objects:

Near the bottom of this table you can (faintly) see the text object. Click that link and you'll be presented with (9 pages of ) full-on anatomy of the text object, including illustrations and example code. Jackpot.

Microsoft: DOM, the Sequel Historically speaking, Netscape was the first out of the gate with their Document Object Model, originally implemented for developers in Navigator 2 and accompanying the birth of JavaScript 1.0. Microsoft essentially attempted to replicate Netscape's DOM for use in their Internet Explorer 3 browser. Because Netscape did not publish specifications for their early DOM or for JavaScript, and because Microsoft needed IE 3 to be compatible with Navigator (which was then the de facto standard), Microsoft was left to basically reverse engineer

the Netscape DOM and JavaScript language, somewhat like re-creating a building without the original blueprint in hand. The result, unfortunately, was less than stellar compatibility: Internet Explorer 3 possessed many bugs and incomplete implementations of various DOM components. After receiving heated negative energy from developers, Microsoft dug in their heels in preparing Internet Explorer 4 and re-approached their DOM with a new outlook. Whereas Netscape was planning several modest and a couple of significant additions to their DOM for their fourth generation browser (most notably, style sheets and layers, which are arguably one in the same), Microsoft went on the offensive. Rather than a tepid upgrade, the Internet Explorer 4 DOM was extremely ambitious, attempting to break down the anatomy of the page into many more, smaller, more manipulability components than the Netscape DOM attempted. Both companies touted their new DOM's as the bearers of "Dynamic HTML," but in reality Microsoft's implementation was far more "dynamic." Microsoft's IE 4 Document Object Model was a hit with many developers, who began to migrate towards MSIE as their web development environment of choice. Combined with the proliferation of the MSIE browsers among users (since it became part of the operating system, nudge nudge), Microsoft was in control of the browser market. With the release of IE 5, Microsoft built upon the DOM foundation laid in version 4, with a variety of refinements. Overall, however, the structure of Microsoft's DOM has remained intact between IE 4 and IE 5. To further encourage developers, Microsoft has published its DOM documentation in a very accessible format on the Web. Microsoft's

MSDN Web Workshop contains a clean reference of Document Object Model components. Unlike Netscape, Microsoft has kept their DOM reference distinct from their JavaScript (a.k.a. "JScript") reference material, the latter that can be found at the Microsoft Scripting Technologies site. Unfortunately, Microsoft has a habit of shuffling their web pages frequently; so direct bookmarks to these sites may become extinct. Turning to Microsoft's beneath DOM the reference, you will find several objects,

subheadings

"DHTML

References"

topic:

properties, methods, and events should all ring familiar by now. The convenient structure of Microsoft's documentation allows you to cross-reference information via each of these indices -- thus, if you want to look up a property whose name you recall but whose owning object you do not, use the properties index. Once you click on a chosen property, the information sheet will report the objects to which it can belong (under the subheading "Applies To"). Microsoft also indexes an additional topic, which they call collections. A "collection," in Microsoft verbiage, is an array-based object. For example, the applet object contains properties and methods reflecting Java applets embedded into a page using the <applet> tag. However, the applet objects are contained within an array called applets[], and so you refer to a specific applet object via its index in this array; e.g. applets[2]. Thus, the entry for the applets array is listed in Microsoft's "collections" index, while the entry for the applet itself resides in the "objects" index. Surfing through the index of objects in Microsoft's DOM, you can quickly see that it supports many more than the Netscape DOM.

Cleverly and conveniently, Microsoft has published their DOM so that it is easiest to reference while using MSIE 4. For instance, we'll look up the table object (an example, by the way, of an object which is not supported in the Netscape DOM). The reference sheets, seen below, contain quite a bit of information -- using the drop down menu you can switch between views of supported properties, methods, and events. The documentation will also indicate whether the component is new to IE 5, as compared to IE 4, via a note "This feature requires Microsoft Internet Explorer 5 or later" on the reference page.

Armed with the above documentation, the DOM's are at your fingertips. Despite the fact that the entries may appear long and intimidating, most objects are constructed along the same patterns. In practice, reading the DOM reference typically boils down to verifying what properties and methods do or do not belong to a particular object and, in some cases, how exactly they behave. DOM of the Future "Where is this all leading us?" you might wonder with heady glee. Clearly, one of the major themes of this article has been that the two major Web development environments -- Netscape and Microsoft's browsers -- do not share compatible Document Object Models. Whether or not you believe that they should be compatible at this level

most likely depends on whether you are a developer, a user, or a shareholder. The W3C's Document Object Model Level-1 and Level-2 specifications could go a long way to resolving incompatibilities between the browsers, but it is no golden cure. For one, W3C recommendations are only useful if a developer adopts them. There is no law forcing Microsoft or Netscape to implement the W3C DOM. In looking for an angle to catch up to Microsoft's market share, Netscape is touting Netscape 6's superior compliance with the W3C standards, based upon the open-source Mozilla project. Still, Microsoft may or may not play along. If you are sympathetic to the Web Standards Project ("WaSP"), an activist group of high-end Web developers who support convincing and/or shaming the Big Two into supporting common web standards, you can join the ranks of those holding out hope for a common Document Object Model. Can't we all just get along?