Nov. 14, 1997 Issue > Web Authors

The Document Object Model Explained

It's Not What Documents Say; It's What They Do

By Dale Dougherty
Rank: 3

Until recently, a Web page had no backbone, no ability to act on its own. A Web document had no structure by which you could control how it works. The document was a container of static information. If you wanted to interact with the user, you needed to write applications in Java or CGI. The document was often an end result of an application.

That's changing with Dynamic HTML. Documents themselves are becoming applications and the nature of these documents is changing from passive to active. The Document Object Model is the underlying structure for these information-intensive applications, and it serves as a foundation for developing documents that do what they say.

In this article, we explore the Document Object Model and what it means for Web developers, especially as it begins to emerge as an important standard from the World Wide Web Consortium.

Documents Are Applications

If documents are becoming applications, developers need to setup and manage a set of interactions with a body of information.

The document becomes a user interface to information, much like a book or magazine is, but with the added dimension of user interaction that can transform the interface and the information.

Basic HTML is a static data format. How the browser renders the various elements of an HTML page is a behavior that's hard-wired. With Dynamic HTML, the Web developer can change these behaviors to create and control new kinds of behaviors. Such behaviors may be defined by scripts using JavaScript or as formatting properties using Cascading Style Sheets (CSS).

An object model is a backbone to support these behaviors. It is a common framework that organizes how behaviors are referenced and how they act upon information and interact with each other -- how scripts reference elements of a document; how styles are applied to elements; how scripts change styles or how styles initiate scripts.

Object Models

If you ever played with HyperCard, you might recall its object model. A HyperCard application is a stack of cards. There are five kinds of objects in HyperCard: Buttons, fields, cards, backgrounds and stacks. These objects were organized as a hierarchy with buttons and fields at the lowest-level and stacks at the highest level. The HyperCard developer needed to understand this hierarchy to know how to write scripts that act upon user events.

The Document Object Model for the Web is more abstract than HyperCard but it has a similar purpose. If you are a JavaScript developer, you've had to learn about events and objects. Until 4.0 browsers introduced Dynamic HTML, JavaScript could not address and manipulate the contents of a document -- at least not in a general way. Netscape and Microsoft each introduced their own Document Object Model with the release of their 4.0 browsers, which as usual was similar but different. The Level 1, or Core Document Object Model Specification, from the W3C is an early stage effort to make sure that both browsers will share a common Document Object Model.

Models Are Structures

The Document Object Model is a document tree that is made up of any number of nodes. In other words, it defines an object hierarchy. The Node object is a single node on the document tree and the Document Object is the root node of the document tree.

Each node of the document tree may have any number of child nodes and all nodes, except the root node, will have a parent node. Each node is numbered sequentially and can be named. So the DOM spec provides the developer with a number of ways to use this generic document tree. A script might reference a node by an absolute or relative position -- the first node or the next node, for instance. A script might insert or remove a node.

Objects Are Containers

Think of objects as labelled containers. Behaviors will access and manipulate objects and their contents.

The Document Object is the container for all the objects defined in an HTML or XML document. The Document Object provides access to the Document Type Definition (DTD), if it is an XML document. It also provides access to the root level element of the document. For an HTML document, this is the <HTML> element. In an XML document, it is the outside or top-level element.

For practical purposes, the document tree is an ordered collection of elements. An element is an object that contains all the content between the start and end tags of the element as objects, and any set of attributes that are defined for the element.

Each element has a name (its tagname). In the example below, the H1 element has an ID attribute that uniquely identifies it.

<H1 ID="sect01">The Big Easy</H1>

These elements can also be nested; in other words, each element object is a container for other elements. In an HTML document, the <HEAD> element typically contains a <TITLE> element.

The most important thing about objects is that you can reference them and their contents. For instance, JavaScript allows you to reference the title of a document as follows:

document.title

Which produces:

The title of this document is:

With XML, you can define your own set of elements, which means you don't have to rely on the fixed set of tags available in HTML. You can create objects based on the semantics of an application and then access those objects in scripts and styles sheets. However, you will probably want more than the object itself; you will want to know the context of the objects in a document. That's why a script may look at the parent of an object to establish the context.

Additional Objects

We've covered the primary object types: Nodes, documents, elements and attributes. The spec also defines the following objects:

• A Comment object is the contents of a comment, defined as the characters in between <!-- and -->.
• A PI object is a "Processing Instruction," defined as content between <? and ?>.
• A Reference object used for named entities and parameter entities, but not numeric character entities. NamedCharacterReference is a subtype of Reference for character entities such as <.
• A NumericCharacterReference subtype for numeric literals such as <.
• A Text object contains data without markup. This will often be a child object of an element.

Working with DOM

The Document Object Model establishes two basic kinds of relationships. The first is derived directly from the ability to traverse the object hierarchy.

Given an object, you can find out where in the document tree it is located. You can refer to the parent or the child of this object as well as siblings of this object. If you were writing a script to manipulate the outline of a document, you can use these references to walk up or down the document tree. This can be done using the NodeList object, which is an ordered collection of Nodes.

Section 1 -- Parent of section 1.1
       Section 1.1
               Section 1.1.1 -- Child of section 1.1
       Section 1.2 -- Sibling of section 1.1


The other is the ability to access a collection of objects by name. In a cookbook, consisting of sections filled with individual recipes, the recipe itself is a class of an object, and each instance of that class can be referenced. Thus, it might be possible to create an index of recipe titles by iterating over a list of nodes for document.recipe.title. This might be done using the NamedNodeList object, which represents collections of Nodes that can be accessed by name.

DOM as API

The mission of the DOM spec is to articulate a common Document Object Model and establish the primary application interfaces (API). In essence, an API describes the handles that a developer can use to reference objects and methods.

Netscape, Microsoft and other software developers will be responsible for implementing the DOM spec for a given language, such as JavaScript, VBscript or even C and Java. The DOM spec uses a kind of generic language called IDL (Interface Definition Language) to define the interfaces.

The DOM introduces the notion of hierarchy into the sprawling hypertext world of the Web. Intelligent applications and tools will be able to key off the structure, and the semantics associated with them, so that documents will be able to do a lot more for us.

The DOM Tutorial
The Dynamic DOM Specification
All Differences Will Disappear
Dynamic HTML Authors Welcome DOM
Recent Quotes
The Document Object Model Explained