Coding 101: An Introduction to the Document Object Model

So for the first time since starting this new code-oriented blog of mine last fall, I’m finally starting to learn enough about coding to feel confident in writing a few beginner’s tutorials; but please understand that this is a fellow beginner writing these, so I hope you’ll drop me a line at ilikejason@gmail.com if you see something in essays like these that needs correcting.

The main language I’m learning in more depth these days is JavaScript (and the accompanying jQuery, Ajax and JSON format); and one of the things about it that really confused me when I first learned about it at DevBootcamp, but that I’m really starting to understand at a deeper level, is what’s known as the Document Object Model, or DOM. See, you can think of most “models” in just about any programming language to be essentially a set of definitions for how some specific thing works; and when it comes to web browsers, all the various ones on the market have agreed to treat the HTML web pages they’re served in this standardized sort of way, with different sections they’re looking for and these sections defined by very specific words. Any webpage a browser serves up is known in tech talk as a “document;” and any distinct thing in a document is an “object;” and there is a certain “model” that defines how these objects are parsed and understood by all browsers out there, no matter which organization made it or for what purpose; hence the document object model or DOM.

The very top of the model’s map is the document itself, the literal page of code that’s fed to that browser for possibly rendering and showing us (if everything goes well, that is); so in JavaScript, anytime you see a piece of code that’s referring to a “document,” like so…

document.getElementById(‘price’);
var pageAddress = document.url;
document.write(‘<h1>Here is some extra new code!</h1>’);

…that’s JavaScript telling the browser, “Look at the entire page when you’re trying to do this thing” (whether finding a section of that page with the ID “price,” like the top example; assigning the page’s URL to a variable called pageAddress; or adding a new line of HTML code to the page). That’s step one; there’s nothing higher than this in the DOM.

The next step down from the entire document, then, is the declaration that it’s an HTML file, which let’s not forget looks roughly like this on an HTML page…

It’s essentially a container for everything else on the page, which is why it’s directly one step down from the “document” and one step up from everything else.

After that, the general sections you typically find in an HTML document — a head section for declaring information about that page, a body section where the public content goes, etc.

And one level down from this, the typical things you might find within such generalized sections — a reference to a script in the header, for example, or various dividers for displaying various parts of your page. Anyone who’s read or written HTML is hopefully starting to pick up on what’s going on here at this point; all these various things are written in HTML as a series of opening and closing tags, with everything between those tags being considered part of that section, and in turn each of these ever-smaller sections appear one direct level below its enclosing section in this DOM tree that one can climb up and down, just like going up and down an actual tree. Each one of these separate objects, then, are known as a “node” in the parlance of the DOM language itself.

Oh, and it just keeps getting further and further enmeshed, like a Russian nesting doll that never ends: a divider within a section will undoubtedly contain tags for formatting its text, like header tags, paragraph tags and list tags; then there might be an italicized part of the text within a paragraph, or of course list items that are part of a list; and finally there is the text that the visitor actually reads with their human eyeball, which is a node unto itself.

And then finally, don’t forget that all HTML elements can have classes or IDs attached to them via CSS, for defining the attributes of that part of the page; and these are a node too, although are sideways in importance to the element on the DOM tree, not above or below. This is basically how every browser in existence understands “how a page of HTML should work;” and although different browsers may render these elements in slightly different ways, they all at least know to render it in this kind of order.

So then, now we finally come to the most important questions of all — why is it important to think of these HTML sections as “nodes” to begin with, and why is it so important to get the order of that tree right? Well, with JavaScript at least, that’s because there are commands that let you skip straight to a specific node and either read or write information to it, a pretty powerful part of the language…

var banner = getElementsByTagName(‘h1’);

…but then there are other commands that let you choose a new node simply in relative terms to the previous node, which is even more powerful…

var bannerText = banner.firstChild;

This line above, for example, grabs just the text “Welcome to my page!,” which as we can see in our tree is the “child” node of the h1 tag’s node, and that would’ve more difficult to do if there wasn’t the opportunity to just reference the child of h1.

There are of course many, many other ways to manipulate the elements of an HTML page through JavaScript, from changing the entirety of an element to just adding or removing a class tag, adding an entire new node from scratch, and more, which is why JavaScript is the main language responsible for all the cool little updates you see on a web page while you’re interacting with it (otherwise known as the “front-end development” of a website, the kind of job I’m out trying to get these days). But to get this manipulation right, you have to understand how to traverse up and down the document object model’s hierarchy; and as you can see, that can be tricky if you don’t understand the concept of each and every element being its own standalone node, and the way that these nodes relate to each other in the hierarchal tree you’re climbing up and down.

I hope this is of some help to all you who found this through a Google search on “what the frak is a document object model anyway,” and do make sure to check my “Adventures in Codeland” blog on a regular basis throughout the year for more beginner’s tutorials like these. And like I mentioned, if I did manage to get something above wrong (God forbid!), I hope you’ll drop me a line at ilikejason@gmail.com so I can correct it and make this as informative a tutorial as possible. See you soon!