What is the DOM?

Trying to explain the DOM simply. Failing. Trying again.

A friend of mine recently asked me,

What is the DOM?

I began rambling my way around a non-technical answer. With much hand-waving, I eventually failed, pointing her to the W3C specification. Which was about as helpful as giving a copy of the Tetrabiblios to a carpenter asking about angles.

Yoda I was not.

My incoherence bugged me.

If you can't explain it simply, you don't understand it well enough.

So here goes, a definition of the DOM where you don't need to know anything about structured groups of nodes, object-oriented programming, or the W3C:

The DOM is a set of conventions for changing a website with code. Websites are viewed in programs called browsers. These browsers use certain conventions. For example, there is a convention to make your website red. And a convention to make your website blue.

These sorts of simple definitions are important for beginning programmers--or for anyone trying to master any craft with a lot of new abstract terms.

Consider this code snippet:

package_list=(
    vim-gnome
    exaile
    diodon
    cmus
    gimp
    calibre
    imagemagick
)
sudo apt-get install -y ${package_list[@]}

Whatever language that is, it is certainly not English.

What does all this have to do with the DOM? Well, the DOM is a whole new language. It's the language that web browsers speak. And like any new language, it has a huge new vocabulary and its own syntax.

So the first word of vocab? "Document." The first letter in DOM stands for "Document." (The other two letters are "Object" and "Model," but those aren't important for now.)

The document is the root, the core, of every web browser. Each individual webpage is a document. Specifically, an HTML document.

So we have two new words of vocab. "HTML Document." AKA webpage. We want to change that document with code? We use the DOM.

Let's stop there for a bit. The key to learning something technical is to limit the number of new abstract terms.

Experienced programmers develop a sort of sixth sense for which abstract terms are important. There's a sort of filter that passes over the vast majority of the terms.

Last night I read about Go for the first time.

Most of what I read I filtered out. Mostly I just let the words wash over me, trying to sense the contours of the ideas. I tried to draw simple analogies between what I already knew and what I was reading. In Python, I know about how "import" and "PYTHONPATH" work. For Go, I imagined "import" and "GOPATH" behaved exactly the same way.

Now does GOPATH behave exactly the same as PYTHONPATH? Probably not. When I actually sit down to use GOPATH, I'm sure I'll run into issues. But that understanding got me through the section. I have a basic idea how to import code.

Now what does all this have to do with the DOM?

Well, when reading about the DOM anywhere online, there are going to be an endless stream of abstract terms. Be like a pro. Rush these documents. Gallop out of the Helm's Deep of ignorance. Charge through until you reach the Gandalf of understanding.

Now time for abstract term number two: "body." The body of a webpage is the part of the webpage you actually see. The other parts are behind-the-scenes. They affect the webpage. But you don't see them directly. (What are the other parts? Who cares? Right now all we care about is the body!)

If I put "Bob is an idiot" in the body of the webpage, the webpage is going to show "Bob is an idiot."

So the body is a part of the webpage (aka the document aka the HTML document). So if I want to access the webpage with code? Here it is:

document

And if I want to access the body?

document.body

Which is just another way of saying "webpage.body" or "HTML-document.body". But some human being somewhere made the first web browser long ago. And decided you refer to the webpage itself with the word "document". And the convention caught on.

Maybe it was more complicated than all that. Maybe it is a lurid tale, filled with subterfuge and skullduggery. Maybe there were rival camps, some who wanted to use "document" and some who wanted to use "webpage". Maybe the "webpage" camp all fell on their swords when they lost the debate. Maybe they are still waiting in the wings, biding their time, waiting for the chance to strike.

But for now the convention is "document". And to get at the body, "document.body". And to get at the style of the body?

document.body.style

The style controls how the webpage looks. Let's say you want to change the font of the webpage.

document.body.style.font-family

Why font-family? Because someone sometime somewhere somehow decided. That's the convention.

Now how do you set the font-family to, say, Arial font?

document.body.style.font-family = "Arial"

How about courier?

document.body.style.font-family = "Courier"

And so on and so forth. You could do "Helvetica". Or "Times New Roman". Or whatever.

How about the convention for changing the background color of a webpage?

document.body.style.backgroundColor = "red"

And for blue?

document.body.style.backgroundColor = "blue"

For extra credit, on any website, open the javascript console of your browser, enter the above code, and hit enter. Watch as the background automagically changes!

And what is the name for all these conventions by which code changes webpages?

The DOM.