Getting Ready for the W3C DOM

Forwarded: Tue, 19 Oct 1999 16:20:16 -0400 Forwarded: gannon@iuvax.cs.indiana.edu Received: from webwisdom.com (lem.npac.syr.edu [128.230.21.157]) by postoffice.npac.syr.edu (8.9.3/8.9.3) with ESMTP id RAA27594; Wed, 6 Oct 1999 17:31:22 -0400 (EDT) Message-ID: <37FBC0C1.2CAD7D9E@webwisdom.com> Date: Wed, 06 Oct 1999 17:36:01 -0400 From: Marek Podgorny Reply-To: marek@npac.syr.edu X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: gcf Subject: Getting Ready for the W3C DOM Content-Type: multipart/mixed; boundary="------------D15F82D34CAE002DD9E60384" Content-Length: 55704 This is a multi-part message in MIME format. --------------D15F82D34CAE002DD9E60384 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://developer.netscape.com/viewsource/goodman_cross/goodman_cross.htm --------------D15F82D34CAE002DD9E60384 Content-Type: text/html; charset=us-ascii; name="goodman_cross.htm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="goodman_cross.htm" Content-Base: "http://developer.netscape.com/viewsour ce/goodman_cross/goodman_cross.htm" Content-Location: "http://developer.netscape.com/viewsour ce/goodman_cross/goodman_cross.htm" Getting Ready for the W3C DOM

T H E J A V A S C R I P T A P O S T L E

Getting Ready for the W3C DOM

By Danny Goodman

Send comments and questions about this article to View Source.

You don't have to be a veteran JavaScripter to have suffered through the frustration of developing interactive web applications that run on a wide range of browsers. The primary challenge has been reconciling sometimes vast differences among document object models implemented across generations and brands of major browsers. I'm happy to report that as I stare into the dark tunnel of incompatibility, I see a pinhole of light that isn't another train racing toward me: the Document Object Model (DOM) specification from the World Wide Web Consortium (W3C), and version 5 browsers. But before you get out your party hat, it's important to know what impact the W3C DOM, as implemented in the Mozilla NGLayout (next-generation layout) engine (known to some as Gecko) and Microsoft Internet Explorer 5, will have on both your existing applications and your future authoring.

In this article, rather than bore you with a complete rundown of DOM features, I'll instead focus on how you should start thinking about HTML documents in anticipation of building dynamic pages in the future. A number of concepts (particularly nodes) will be new to those of you who aren't trained in computer science. Equally important is knowing how much of your existing knowledge transfers immediately to this New World. I'll also try to point out some of the potholes in the road that leads to the New World, in case you need to update applications that must work in the Old World as well.

A DOM standard, like the one produced by the W3C, has been a tantalizing promise for some time. Members of the scripting community have begged for such a standard ever since they had to write their first browser branching statements. The good news is that we got what we wanted; the bad news is that we got what we wanted.

THE W3C DOM'S STRUCTURE

As of this writing, the W3C has released the final specification for DOM Level 1. Level 2 is under discussion and may be completed before the end of 1999. The purpose of the Level 1 specification is clearly expressed in the W3C document, which defines the standard as

a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents.

"Hooray!" the crowd roars.

When your document world consists entirely of HTML, this sounds like a relatively simple goal to reach, given so many existing object models that could be used as source material for a new specification. But the mission of the DOM working group extended beyond HTML documents to include Extensible Markup Language (XML), which uses tags as a way to give structure, context, and meaning to any collection of textual information. HTML documents have many characteristics that don't apply to XML, so the working group defined a basic interface that could apply to both HTML and XML documents. Thus, the Level 1 standard is divided into two parts:

Core
HTML

The Core DOM is where most concepts that are new to scripters appear. By and large, Core DOM concepts are unlike anything you've scripted in HTML documents before for any browser. I'll go over the highlights later in this article. In contrast, the HTML DOM, which builds on the fundamentals of the Core DOM, will look familiar to you, as I'll demonstrate in a moment.

The Level 1 DOM didn't address some issues that are very important to application authors who want to implement cool Dynamic HTML effects. The hottest potato tossed around the working group table (and temporarily dropped) was the issue of events. Events have been a thorn in cross-browser developers' paws because of the very different ways that Navigator 4 and Internet Explorer 4 propagate events (trickle down vs. bubble up, as described in an earlier article, Dueling Event Models - A Cross-Platform Look). Fortunately, the issue is being addressed by the Level 2 DOM working group and will likely be resolved before the NGLayout engine becomes final. Other big issues covered by Level 2 are scriptability of style sheets and the Range object (analogous to the IE4 TextRange object).

WHAT STILL WORKS THE SAME

If you take the time to peruse the W3C DOM Level 1 specification, particularly Appendix E (the recommended implementation syntax for ECMA-compatible languages, such as JavaScript), a lot of the terminology will look brand new. Fortunately, that's not really the case.

The HTML DOM, while more extensive than the ones implemented in Navigator browsers through version 4, is predominantly a superset of the object models that have been in place since the dawn of browser scripting: Navigator 2 and Internet Explorer 3. For example, you see in DOM Level 1 that the document object, FORM element, and Image object have the familiar properties and methods listed in Table 1.

**Table 1. Familiar properties and methods in DOM Level 1**
`document` object		`FORM` element		`Image` object
Properties	Methods	Properties	Methods	Properties
`anchors[]`	`close()`	`action`	`reset()`	`border`
`applets[]`	`open()`	`elements[]`	`submit()`	`height`
`cookie`	`write()`	`length`		`hspace`
`domain`		`method`		`lowSrc`
`forms[]`		`name`		`name`
`images[]`		`target`		`src`
`links[]`				`vspace`
`referrer`				`width`
`title`
`URL`

Input elements have value properties, checkboxes and radio buttons have checked properties, select objects have options, each of which has a selected property, and so on. Very familiar stuff.

The bottom line is that with rare exceptions (described below) basic scripts that run on earlier browser DOMs - including those that perform image swapping (that is, mouse rollovers), form validation, frame or page navigation, and form manipulation - should be immediately playable on fully compatible W3C DOM browsers.

WHAT GOES AWAY

The transition to the W3C DOM, however, is no easy stroll down memory lane. Some object model features that we've come to know in Navigator 4 and IE4 no longer apply. While IE4 proprietary constructs persist in IE5 (in parallel with many, but not all, new DOM features), the NGLayout engine jettisons some object model features that you may be using for Navigator 4.

The most notable exclusion in NGLayout is the <LAYER> tag and, by extension, the Layer object. Your reaction to the loss of the LAYER element will depend on whether you've been developing solely for Navigator 4 or for cross-browser viewership. If your designs are for Navigator only, you've probably come to rely on the Layer object and its properties for linking in external content, doing dynamic positioning, changing visibility, and stacking. You'll have to change your layer objects to positioned DIV elements.

But if you write cross-browser DHTML, you may currently regard the NavigatorLayerobject as a necessary evil. Navigator 4's occasionally ill-tempered treatment of positioned DIV elements sometimes requires that you write branching code to generate a <LAYER> tag instead. And branching or other techniques are needed to accommodate object references to traverse the gnarled document.layerName.document... hierarchy. In lieu of LAYER, you should appreciate the more standardized and predictable behavior of positioned elements that come with the NGLayout engine (and use the IFRAME element to link in external HTML content).

WELCOME CHANGES

With the casualty list being quite small, it's heartwarming to know that the W3C DOM brings with it many welcome changes to the objects you script. Topping the list of W3C DOM features that put a smile on my face is the formal exposure of all elements in an HTML document as scriptable objects. IE4 scripters are well aware of the power of this capability, particularly in creating dynamic content. That's not to say that the W3C DOM has implemented the Internet Explorer object model verbatim: the Level 1 DOM includes a relatively sparse set of properties for HTML elements (className, dir, id, lang, and title). But, as I'll demonstrate, the combination of the Core DOM and HTML objects provides a good start at truly cross-browser DHTML.

The W3C HTML DOM has a much greater sense of document and tagging structure than what you may be accustomed to. For example, document and document.body are entirely separate objects - and logically so. The document object's scope is that of the entire HTML file, from top to bottom. In fact, the <HTML> tag itself is an element that's exposed as an object belonging to the document object. In contrast, the document.body object encompasses only the elements contained within the <BODY>...</BODY> tag pair as well as attributes assigned to the <BODY> tag. This is a slight departure from what you already know, because some properties in previous object models ascribed to the document object become properties of the body object in the W3C DOM. Table 2 compares the properties of the "old" document object from Navigator 4 against the document and body objects of the W3C DOM.

**Table 2. Old document object vs. new document and body objects**
Navigator 4	W3C DOM
`document`	`document`	`body`
`alinkColor`		`aLink`
`anchors[]`	`anchors[]`
`applets[]`	`applets[]`
`bgColor`		`bgColor`
`cookie`	`cookie`
`domain`	`domain`
`embeds[]`
`fgColor`
`forms[]`	`forms[]`
`images[]`	`images[]`
`lastModified`
`layers[]`
`linkColor`		`link`
`links[]`	`links[]`
`referrer`	`referrer`
`title`	`title`
`URL`	`URL`
`vlinkColor`		`vLink`

In addition, because the body object is an HTML element object, it inherits the properties of all HTML element objects: className, dir, id, lang, and title. This too is logical in the new environment, because you can assign CLASS, ID, and other attributes to the <BODY> tag if you like.

For the W3C DOM to be of value to dynamic content scripting, it enforces the notion of HTML element containment. If you've done extensive DHTML scripting in IE4, this idea should be well ingrained in your head by now.

At issue is how a script can modify the properties of a chunk of content in an HTML document. For many kinds of elements, this is automatic. For instance, an INPUT element is a standalone element whose properties are defined initially by attributes of the <INPUT> tag; however, those property values can be read or modified by script because the attributes are exposed as object properties. But it's quite possible that today you don't define paragraphs as containers. It's not uncommon to find paragraphs as freestanding blocks of text, with <P> tags used as paragraph separators. That may have been acceptable in earlier days of HTML, but now paragraphs should be contained by <P>...</P> tag pairs. In other words, the <P> tag is not a paragraph break: it's the beginning of a paragraph container. If you omit the </P> tag, browsers tend to supply the equivalent end tag right before the next <P> tag in the document. And if you don't surround blocks of text with <P> tags, the blocks become text objects (as distinguished from HTML element objects) owned by the next outermost container (the BODY in most cases).

Although many ancient pages of my own web site are guilty of the sin of improper element containment (please don't send me e-mail to slap my wrists), I now practice better tagging, avoiding the dangling text block at all costs. And even though browsers fill in end tags for elements such as <TR>, <TD>, and <LI>, I religiously include the end tags explicitly in my code. This is in preparation for the dynamic content potential of the W3C DOM browsers.

VITAL NEW CONCEPTS

Now we come to the part where we look ahead to deploying W3C DOM-compliant applications. The concepts covered in this section are governed primarily by the Core DOM, but they fill gaps in the HTML DOM (and they apply to XML as well). The key concepts to grasp are how to create JavaScript references to HTML element objects and what the relationships are among objects within a document.

New Ways to Reference Elements

Because Internet Explorer has until now been the only scriptable browser to expose all HTML elements as objects, you may well be familiar with its syntax for addressing an element by its id property using the document.all array. For example, given the element

<P ID="paragraph1">...</P>

a script could reference that object with

var elem = document.all.paragraph1

As a shortcut, you can also omit the "document.all" part of the reference, and go straight to the object:

var elem = paragraph1

The document.all array is not part of the W3C DOM. Instead, the specification provides a document object method that lets you reference any object in the document by its ID:

var elem = document.getElementById("paragraph1")

The required parameter of the getElementById() method is the ID of the object (assigned to the element's ID attribute) as a string. This method is supported in IE5.

From a practical standpoint, I regard this method as a finger-twisting handful to type repeatedly inside a script; the method name is case-sensitive, and you have to remember to use a lowercase "d" as the last letter. But you can simulate document.all even in a W3C DOM-compliant browser, such as the NGLayout engine. Coming to our aid is a method of the Core DOM document object: getElementsByTagName(). This method returns an array of HTML element objects for a given tag name. You supply the tag name as the sole parameter (in string form) to the method. Here's the neat part: The DOM specification notes that the method accepts a wildcard character ("*") parameter to fetch every tagged element in the document. While IE5 supports this method, it doesn't support the wildcard parameter (it will return an array of length zero) - but that's OK, because we can generate a new property for the W3C DOM document object whenever IE isn't being used:

if (document.getElementsByTagName("*")) {
document.all = document.getElementsByTagName("*")
}

This document.all normalization trick preserves IE's own document.all collection untouched, yet supplies the equivalent for fully W3C DOM-compatible browsers. After that, you can reference objects with ID values the same way in either browser:

var elem = document.all.paragraph1

You must exercise some caution, however. If your scripts add, delete, or replace elements, the makeup of the artificial document.all array doesn't automatically track the changes to the document's structure. You'll need to update the document.all array prior to any script statements that refer to objects.

While we're on the subject of object references, DHTML authors will be happy to learn that style sheet properties assigned to objects via inline STYLE attributes are exposed the same way in IE as in the W3C DOM Level 2 (and implemented in NGLayout). Style sheet properties are accessed through an element's style property. For example, to set the font size of the paragraph shown above, a single cross-browser reference does the job:

document.all.paragraph1.style.fontSize = "14pt"

Ya gotta love it!

Introducing Nodes (and Parents, Siblings, and Children)

A genuinely new concept for many scripters is the node terminology that the DOM uses to describe a document's content and structure. To understand what a node is, let's go back to the topic of element containment in an HTML document. Consider the following simple HTML document, which is formatted to reflect the way elements contain each other:

<HTML>
<HEAD>
    <TITLE>
      A Sample Page
    </TITLE>
</HEAD>
<BODY>
    <P ID="paragraph1">
      This is the
      <EM ID="emphasis1">
        one and only
      </EM>
      paragraph on the page.
    </P>
</BODY>
</HTML>

The document object (not represented by any text in the file) encompasses every tag or other piece of content. The next innermost element from the document object is the HTML element. The HTML element has two nested elements at the same level: HEAD and BODY. The HEAD element's next innermost element is the TITLE element, and the TITLE element's next innermost piece of content is a string of text (A Sample Page). Similar nesting takes place within the BODY element, but extends one level deeper because there's one more element container (the EM element) to contend with.

In DOM-speak, each element container (that is, start and end tag pair) and each text string is a node (or object). If the document had contained a standalone tag, such as <BR>, it too would be a node. This containment hierarchy is usually referred to as a tree, and a node is a point on a branch that can stand alone and is also capable of spawning another branch. (Windows users will recognize this kind of tree structure from the left frame of the Windows Explorer window that shows the computer's volumes, folders, and files.) Here's a tree diagram of the document above:

document
+--<HTML>
   +--<HEAD>
   | +--<TITLE>
   |     +--"A Sample Page"
   +--<BODY>
      +--<P ID="paragraph1">
         +--"This is the "
         +--<EM ID="emphasis1">
         | +--"one and only"
         +--" paragraph on the page."

Each text line in this diagram is a node of the document object's tree. The most common nodes in HTML documents are one of two types: an element or a text node. The sample page, therefore, contains one document node, six element nodes, and four text nodes.

Nodes have relationships with nearby nodes based solely on the organization of HTML elements and text nodes in the document. Every node (except for the document node, which is at the "root" of the tree) has a parent (its next outermost container). Then, depending on the content of the page, a node can have zero or more siblings (nodes at the same level and sharing the same parent, just as a brother and sister are siblings in a family) and zero or more children (nodes contained by the current node). For example, in the simple document diagrammed above, the HTML node has no siblings but two children, HEAD and BODY. The HEAD and BODY elements are siblings. The BODY element has one child, the P element. The P element, in turn, has three children, only one of which (the EM element) is an element node type; the other two are text nodes. The EM element, then, has one child, a text node.

To help you visualize this another way, Table 3 shows a variety of relationships among four selected nodes in the above document tree. The row headings show the actual W3C DOM property names that every node has. For example, the parentNode of the P object is BODY. For each node in Table 3, work your way down the column while looking at the relationships among nodes in the document tree.

**Table 3. Relationships among nodes in the document tree**
Properties	Nodes
	`document`	`HTML`	`P`	"`one and only`"
`nodeType`	`9`	`1`	`1`	`3`
`nodeName`	`#document`	`HTML`	`P`	`#text`
`nodeValue`	`null`	`null`	`null`	`"one and only"`
`parentNode`	`null`	`document`	`BODY`	`EM`
`previousSibling`	`null`	`null`	`null`	`null`
`nextSibling`	`null`	`null`	`null`	`null`
`childNodes`	`HTML`	`HEAD` `BODY`	`"This is the "` `EM` `" paragraph on the page."`	(none)
`firstChild`	`HTML`	`HEAD`	`"This is the "`	`null`
`lastChild`	`HTML`	`BODY`	`" paragraph on the page."`	`null`

I should point out that Internet Explorer 5's implementation of the W3C DOM isn't complete, and some of its omissions affect Table 3's column for the document node. IE5 doesn't treat the document object as a node in the document tree. Therefore, except for the document.childNodes property, the properties listed in Table 3 for the document node return undefined. The properties are valid, however, for the other elements in Table 3.

While the properties listed in Table 3 give a good representation of the relationships among nodes in a document, you won't often use most of these properties when scripting HTML documents. The important properties to know are nodeType (always an integer), nodeName (always the tag name when nodeType is 1), nodeValue (text content of a text node), and childNodes (an array of child nodes). The childNodes array can tell your script how many (if any) child nodes are nested inside an element. If child nodes exist and you need to inspect them, a for loop through the childNodes array is more efficient than messing with firstChild and lastChild properties.

Notice one important point about nodes that represent HTML elements: the nodeValue of an element node is null. You might expect instead that the value would be something akin to the innerHTML property that first surfaced in Internet Explorer 4. The four related IE properties (innerHTML, innerText, outerHTML, and outerText) are not part of the DOM specification (but it sure would be great if the DOM working group could find a way to slip them into the final draft of Level 2). To modify an HTML element's content and be compatible with the Level 1 DOM, you must look to the node object's methods.

Node Methods

To create a new element node by script, you typically begin with the createElement() method of the document object. The sole parameter is a string of the tag for the element. For example:

var newElem = document.createElement("P")

The object generated at this point resides only in memory and is not yet part of the document (it has no parent, siblings, or children). Nor does it have any attributes or content associated with it. You can set attribute values by way of property assignments (the simplest way) or via the setAttribute() method of a DOM element. After creating the element above, you can assign it an ID with either

newElem.id = "newP"

newElem.setAttribute("id","newP")

To give this new paragraph element some text content, you must go back to the document object well once more to generate a node that holds text, using createTextNode():

var newText = document.createTextNode("This is the second paragraph.")

It's now time to start incorporating these text and element nodes into the document. For that we call upon some of the node object methods, the important ones being those listed in Table 4.

**Table 4. Key node object methods**
Method	Description
`insertBefore(newChild, refChild)`	Insert a new child node in front of another child node.
`replaceChild(newChild, oldChild)`	Replace an old child with a new child node.
`removeChild(oldChild)`	Remove an existing child node.
`appendChild(newChild)`	Tack on the new child node after the last child node.

Pay special attention to the scope of all of these methods: they act on child nodes. In other words, it's assumed that these methods will be invoked from a parent node to affect that parent's child node contents.

The first task in assembling the new nodes for insertion into the document is to put the new paragraph and text elements together. Because the new text element will be a new child of the new paragraph element, we can begin by appending the text element to the paragraph element:

newElem.appendChild(newText)

At this point, if you could examine the HTML for the newElem node, it would look like this:

<P ID="newP">This is the second paragraph.</P>

Now comes the insertion of this element into the document. Since the scope of the node methods is from the point of view of the parent, we issue the appendChild() method from the BODY element:

document.body.appendChild(newElem)

To summarize, a function that creates and appends a second paragraph to the simple document shown earlier would be defined and called as follows:

function addPElementToEnd() {
   var newElem = document.createElement("P")
   newElem.id = "newP"
   var newText = document.createTextNode("This is the second paragraph.")
   newElem.appendChild(newText)
   document.body.appendChild(newElem)
}

If you need to replace the text of an element, you can do it via the replaceChild() method or by assigning a new string to the text node's nodeValue property. For example, since the updated simple document now has a second paragraph, we can change the text inside the EM element of the first paragraph from "one and only" to "first". We can do this by either creating a new text node or changing the value of the EM element's child node nodeValue property. Here are the two methodologies:

var newText = document.createTextNode("first ")
var oldChild = document.getElementById("emphasis1").childNodes[0]
document.getElementById("emphasis1").replaceChild(newText, oldChild)

document.getElementById("emphasis1").childNodes[0].nodeValue = "first "

Because these two examples are replacing only the textual child node of an element, all style sheet rules assigned to that element (if any) are immediately applied to the text node when it's placed into the element.

For creating complex HTML to be inserted into an existing document, you can see that this "baby steps" approach of creating elements, assigning attribute properties, and appending textual content can get tedious pretty fast. Imagine doing this for a ten-row, four-column table! DevEdge Champion Martin Honnen has devised one way to attack the problem: You assemble the HTML as a string and use document.write() to plug it into a temporary and hidden IFRAME element, letting the browser create the object model relationships; then you clone the content for insertion into the main document and delete the IFRAME. While this is a clever solution, I hope that the W3C DOM working group adopts the convenience properties of outerHTML, outerText, innerHTML, and innerText so that we don't have to use browser version branching for common dynamic tasks.

THE W3C DOM'S IMPACT ON YOUR DHTML PRACTICES

Like it or not, the object referencing syntax for the W3C DOM is entirely new and is supported (for the most part) only in version 5 browsers. Some web authors have been sitting on the DHTML sidelines to let the standards flesh themselves out; these authors may want to generate dynamic content only for DOM-compatible browsers, letting all other versions (including Navigator 4 and IE4) be served with the same "dumb" content as even earlier browsers. But if you want dynamic content to work on both version 4 and version 5 browsers, you'll have to massage your code for a third branch (Navigator, IE, and now DOM) wherever HTML elements and styles are modified. DHTML scripting written for version 4 browsers most likely won't work in the NGLayout engine without modification. Internet Explorer 5 has numerous holes in its W3C DOM implementation (see a compatibility analysis performed against third-party test suites), but if you're aware of these boundaries, you should be able to get a fair amount of the same code running in both NGLayout and IE5, at least for common DHTML operations.

Note: Browser sniffing for DOM-compatible browsers isn't as clear-cut as you might like. While Navigator 5 will report a navigator.appVersion of 5, Internet Explorer 5 reports 4. The version 5-ness of IE5 is detectable via the string "MSIE 5" in the navigator.userAgent property. For examples of how this works, see the article Updating Your JavaScript and CGI Scripts for Version 5 Browsers.

Dynamic Styles and Positions

The impact of the W3C DOM on existing code that modifies style sheet properties and positions isn't large. In fact, it works in the scripter's favor, because the syntax used in NGLayout and IE5 is identical (modulo the CSS properties that aren't implemented in IE5). As an exercise to see what the difference would be, I recalled an example from an old View Source article of mine (CSS-Positioning - The Dynamic HTML Neutral Zone) that converted a Netscape-only "swimming fish" example to cross-browser DHTML.

So that you can see the difference more clearly, I stripped out the comments from the original and rewrote it just for DOM-compatible browsers (that is, it assumes that the browser sniffing is done before the pages are reached). You can compare the two pages of source code side by side. The only change to the HTML portion was to move the style sheet rule for the fish object from the <STYLE> tag to the STYLE attribute of the fish's DIV element. This is necessary because the style property of an element object reflects styles only when they're set as inline attributes of the element.

As for the scripting code, you can see that the number of lines has shrunk. Gone are the numerous browser branching statements. You see a unanimity of syntax for changing style properties. And since the composition of the objects on this page doesn't change while the user works with the page, it's easy to apply the document.all normalization trick described earlier in this article.

Dynamic Content

How your existing practices must change to accommodate dynamic content with the W3C DOM depends largely on how complex the dynamic content is. For example, a lot of scripters would like to modify the string content of a table cell. This is relatively easy, provided you assign ID attributes to each TD element. For example, let's say your HTML includes a table with five columns and ten rows. The cell IDs are just like a spreadsheet cell identifier, where the ID "A1" means "column A, row 1." To swap some text in cell B3 in a W3C DOM-friendly way requires only the following:

var newText = document.createTextNode("New cell text.")
var cell = document.getElementById("B3")
cell.replaceChild(newText, cell.childNodes[0])

When the dynamic content involves combinations of HTML elements and text nodes, the DOM methodology gets more complex, since you have to create the elements or text nodes and assemble the objects in the desired sequence.

BEWARE OF IMPOSTORS

You'll be hearing and reading a lot more about the W3C DOM in the months ahead, as more web authors start implementing pages that are compatible with it. Let me caution you about usage of the DOM acronym. When I see "DOM" in all uppercase letters, I expect to be reading about the DOM specification from the W3C, not about proprietary object model features. In my opinion, articles that refer to proprietary extensions as being part of the DOM leave the reader with the wrong impression. Therefore, in the case of the innerHTML and innerText properties described above, until they become part of the W3C DOM I consider them part of a browser's own document object model (lowercase), even if they were to be implemented by all popular browsers. Distinguishing extensions (which are perfectly OK with me) from the genuine DOM helps developers know what's safe for cross-browser development.

I mention this because I've seen articles that refer to a property or method as being part of the DOM, when a look at the W3C DOM documentation shows nothing of the sort. Know your sources, and hope that they make the proper distinctions.

Note: This same phenomenon occurs in articles about Cascading Style Sheet features that are proprietary to one browser or another. Just because some vocabulary looks like CSS syntax, that doesn't mean it's a CSS feature. Only adoption by the W3C in a final recommendation should allow that feature to wear the official label.

WE ASKED FOR IT

There's little question that the transition to the W3C DOM will be painful for some web authors who have invested heavily in cross-browser DHTML applications that are expected to run in a DOM-friendly world. For others it will be a liberating experience - freedom from the tyranny of proprietary features for a suitably high common denominator of functionality. That's not to say that all implemented behavior will be identical across version 5 browsers, but the situation is certainly improving. I know that the sooner I can banish all those isNav and isIE global variables from my code, the better.

View Sourcewants your feedback!
Write to us and let us know
what you think of this article.

Danny Goodman is a JavaScript/DHTML consultant and the author of two hot-selling books in the web authoring world: Dynamic HTML: The Definitive Reference (O'Reilly & Associates) and the JavaScript Bible, 3rd edition (IDG Books). His latest creation for one of his clients is the Invisible Worlds SpaceKit Viewer.

(9.99)

For more Internet development resources, try Netscape TechSearch.

DevEdge Online FAQ
Developer Response Center
Join DevEdge Program

--------------D15F82D34CAE002DD9E60384 Content-Type: text/x-vcard; charset=us-ascii; name="marek.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Marek Podgorny Content-Disposition: attachment; filename="marek.vcf" begin:vcard n:Podgorny;Marek x-mozilla-html:FALSE org:NPAC, Syracuse University adr:;;111 College Pl.;Syracuse;NY;13244-4100;USA version:2.1 email;internet:marek@npac.syr.edu title:R&D Director tel;fax:(315) 443-1973 tel;work:(315) 443-4879 x-mozilla-cpt:;0 fn:Marek Podgorny end:vcard --------------D15F82D34CAE002DD9E60384--