How the Document Object Model allows you to describe the elements on your Web page, and why that's a good thing.
How would you describe your Web page without mentioning its content?
One way would be to describe the page's structure. What tags are on the page? How many are there? What order are they in? What are the properties of these tags? And finally, what is the presentational nature of each element? This is what the Document Object Model does. It expresses the structure of an HTML document in a universal, content-neutral way.
One of my first articles was the blinking-lights piece. I created it by twiddling with the image tags on a page so they pointed to different image files over time. It was a simple concept: You have an arbitrary number of images on a page, a few of which the computer would randomly change about five times a second. The effect was a flashing, mutating space that I liked a lot.
I didn't know it back then, but what I was doing was manipulating the Document Object Model of that page. I had a number of objects on the page. My script would then query out the number of images, and then modify an attribute of that object (i.e., switch out the sources of the images).
This was about the limit of what you could do with the Document Object Model in Netscape 3. You could read and write the attributes of image and anchor tags,
and you could query some information about the browser itself - what MIME-types it accepted, what plug-ins were installed, its location, and a few other things. Simple, basic, down-to-earth, level-zero items.
Navigator 4.0 has introduced a few new items that communicate what's in a document. Now there are layer tags that create a tree of hierarchies, plus new and more powerful ways to query the width and height of containers (that is, layers and div tags) as well as the window itself. All these add up to some attributes that allow you to manipulate your page and make it do what you want - either as the page loads or over a period of time.
Until recently, this object model was contained in JavaScript, and if you wanted other elements (Java applets, plug-ins) to manipulate any of this model, they'd have to negotiate with the JavaScript scripting engine, which Netscape has dubbed LiveConnect.
With Navigator, it was more useful to think about the object model as a function of JavaScript. The syntax was JavaScript and the collections of objects looked and acted like array objects. For most people, there wasn't really a distinction between a page's object model and JavaScript.
Then Microsoft released Internet Explorer 4.0.
As you probably already know, I like this browser, but before you punch into Threads and flame me, please hear me out. IE's DOM is one of the many reasons why I agreed to go to re-education camp.
Internet Explorer 4.0 takes the object model out of the language and puts it into the browser. Instead of having a language that has a conception of various objects on a page, you have a browser that stores the structure and presentation of a page, and opens up that information to a scripting language or compiled component for reading and manipulation. You don't have to figure out how the div tag's position is stored in JavaScript only to discover it's stored differently in VBScript, because that information is all in one consistent format.
You can manipulate HTML using JavaScript as easily as you could using VBScript, as easily as you could using a Java applet, as easily as you could with a compiled ActiveX control, as easily as you could with Cobol.
And this object model doesn't just deal with anchors, images, and embed tags. The entire structure is dealt with. So if you want to get a count of how many <div>s are on a page, or change the fifth paragraph to blue, or modify the CSS-P values of your list elements so they appear to do one of those oh-so-cool "wipes," the objects you manipulate are the same, and the languages you use become a means to that end.
But what can you do with a DOM?
I've been describing the Document Object Model concept to people at Wired Digital, as well as to a lot of my friends who do Web work. What I've discovered is that one of the hardest things to grasp about DOM is what its use is. If you view it as merely a broker between scripts and a document, it's easy to assume the DOM is simply a common syntax. But it's so much more than that.
If stylesheets allow you to perform layout independent of content and structure, then the DOM allows you to make interaction independent of content and structure. It works on the same principle, but from a different axis, one of code instead of design. This is good because it allows you to modify your existing pages and add all of the wizzy flying titles that your boss wants to see.
next page»
