A reader recently wrote in asking me what the DOM was. They said they’ve heard it mentioned and alluded to, but aren’t sure they really understand it.
We can fix that.
But the HTML you write is parsed by the browser and turned into the DOM.
View Source just shows you the HTML that makes up that page. It’s probably the exact HTML that you wrote.
It might look like different code if, for example, you work in template files in a backend language and don’t look at the compiled HTML output very often. Or there is a “build process” that happens after you write your HTML and the code is put out to the live website. Perhaps that HTML is compressed or otherwise changed.
View Source is a little weird actually. The only people that would care to look at that code are developers and all the major browsers have built in developer tools now. It has probably out-lived its usefulness.
When you’re looking at the panel in whatever DevTools you are using that shows you stuff that looks like HTML, that is a visual representation of the DOM! We made it!
Well, yeah, it does. It was created directly from your HTML remember. In most simple cases, the visual representation of the DOM will be just like your simple HTML.
But it’s often not the same…
When is the DOM different than the HTML?
Here’s one possibility: there are mistakes in your HTML and the browser has fixed them for you. Let’s say you have a
<table> element in your HTML and leave out the required
<tbody> element. The browser will just insert that
The most likely case though, is…
Imagine you have an empty element like this in your HTML:
<script> var container = document.getElementById("container"); container.innerHTML = "New Content!"; </script>
div was filled with some, ahem, new content.
If you use DevTools to check out the visual representation of the DOM, you’ll see:
<div id="container">New Content!</div>
Which is different than your original HTML or what you would see in View Source.
Ajax and Templating
Let’s not go off the deep end here, but I bet you can imagine if you were to use Ajax to snag content from elsewhere and put it onto the page, the DOM is going to be very different than your original HTML. The same with loading in data of some sort and using client side templating.
Try going to Gmail and viewing source. It’s just a bunch of scripts and data from the original page load. Barely recognizable compared to what you see on the screen.
mouseenter event on an element. But that “element” is really a DOM node. We attach that listener via a DOM property on that DOM node. When that event happens, it’s the DOM node that emits that event.
This article isn’t nearly nerdy and in-depth enough for me.
Well, the DOM stands for “Document Object Model” blah blah blah. I didn’t want to (and am not qualified) to write that article. Here’s some meaty ones:
- W3C: What is the Document Object Model?
- MDN: Introduction – Document Object Model
- Wikipedia: Document Object Model
Handy tutorial! Ranks right up there with “it’s not a web page if it doesn’t have a doctype” (don’t be shy, we ALL do that facepalm on occasion).
Disagreed. It’s still essential for me.
I think the ability to View Source is vital and should be easy to do. I just think the command to do so should just open up the document in the Sources panel of DevTools, rather than this special unique view isolated in it’s own little weird world.
view source is still very useful, for situations where you actually want to see the markup that was originally delivered. Perhaps you’re fixing up someone else’s site, or you have a dynamically generated page and you need to know what is actually being output.
Being able to look at the generated DOM is unquestionably useful, but knowing what it was built from can be a big help with problem-solving.
Actually, from the article, ::Chris:: stated above, view source has lost its some of the uses after the introduction of the inspecting tools..!
But, it has still got its importance, when we want to simply open the source in sperate window, instead of opening web console & opening relevant tab for viewing source.
Though, it doesn’t takes you energy, it just improves the frustation time, in high peak pressure time (KIDDING!)
View source is still tremendously useful when troubleshooting code you may have not yourself touched previously. Also, View Source vs DOM is entirely different. Sometimes you want to see the state of the browser prior to DOM altercation. Developer tools handle mostly everything from a view-source standpoint but it’s still quick to just view source and see whats going on sometimes.
I believe Chris didn’t mean it’s totally irrelevant by saying that. In most cases we view source as frontend developers, we try to see what may be responsible for the presence of an object in the DOM. To aid specificity and clarity, the inspect element gives us just that. View Source may be useful but really, if I need to get the source of a HTML document, I’ll just mirror the site and open it in my text editor since it’s clearer to read that way
Simple, but of fundamental importance.
Nice article! Guess I didn’t realize the difference between the DOM and source code. Can see how it would be easily misinterpreted.
Really interesting article Chris. I must say even though I knew that the html you write and the dom are different things but visually I took them as one. Now this article has helped me further seperate them. Thanks for this.
Next article… shadow dom??
This is a great article on all that: https://css-tricks.com/modular-future-web-components/
In the simplest of terms, I think it can be said that the DOM is the parsed HTML.
May I have a go at it?
HTML code arrives
Browser interprets HTML and builds a DOM for the page
Browser shows the current state of the DOM, always the DOM.
A HTML document is just a recipe, a set of instructions of how the browser should build the DOM for the given page. What we see in the end is how the browser interpreted those instructions.
DOM – a layer placed between the HTML code and the displayed page – might have been introduced (I’m a beginner, assumption here) to allow for shuffling bits and pieces in there on the client side, before presenting things on the screen. Now it is there and apparently the only way to the screen leads through it.
Strongly disagree. What the dev-tools show you is also the current state of the DOM, the interpreted version of your HTML.
‘View source’ is a life saver allowing you to look at your actual HTML code. If you are doing dynamically assembled webpages, ‘View source’ is the most convenient place where you can check what your code in the first place asked the browser to do. (Checking for messed-up/unclosed html tags and so. (assembling HTML snippets through custom php scripts may not work flawlessly on the first attempt)).
Of course, the w3c validator can give the ultimate service here (given that you can expose your pages online, but that’s not always the case).
Also, you can perhaps dig up the original HTML in the dev-tools too, but it seems to be many clicks away, and its presentation also seems way more awkward than the plain handy full-screen view source.
Nice write up. It’s funny how everyone knows of the DOM- but when you think about it most beginners and some upper level web developers might think of it as some sort of black box.
I think the critical difference between the ideas of DOM and Code is that the DOM can only exist at run time, inside the browser. For 99% of use cases it doesn’t really make a difference but I firmly believe that when teaching front-end authoring of any sort there are a couple of key concepts that must be taught, or at least reviewed.
As an author of HTML you are writing things that will be seen by people via a browser
Therefore, you are writing for the browser
The browser builds an understanding of your code when it reads it, that understanding is called the DOM and it exists inside the browser.
Tags (bits of text that start with < and end with > represent instructions to the browser about how to build the DOM and what different parts of the DOM are.
The DOM can difer from the original HTML if you omit optional tags such as <html>, <head>, and <body>.
If your HTML looks like
Then modern browsers will fill that out with the optional tags before putting the DOM together.
That’s right. I have tried to write a HTML document without closing tag . In “view Source”
mode it doesn’t show me th missing tag. But when i tried to inspect the page with FireBug, it shows me the missing tag . It added it automatically !
Thanks for the article on this!
I’ve been working with HTML for the past 12 years and would feel dumb when someone would refer to the DOM because I had never really looked into the formal meaning.
Super simple explaination. Thanks Chris!
The DOM is a programmatic object-oriented API definition for accessing html and xml documents. This API is defined in the DOM spec using a language neutral semantics called IDL. So in the strictest sense the following is true: The DOM is not altered except when the W3C changes the API specification When you are looking at
document.getElementById("firstheading"), the following is true:
Thanks Chris, awesome and useful article
Great article, with amazing explanatory graphics. Someone, especially beginners can learn something from this. If nothing else Chris is a master article writer and a teacher. Which is why we all subscribe. We know we can learn something from this guy.
Thanks for the quick and short article, was trying to explain it to myself today, and this helps clear it up :D
Thanks for the article Chris! Was always one of those acronyms that was foggy for me. In terms of View Source, I use it quite a bit when approaching potential clients. It give me a quick understanding of how their website works (if have one), and what I can offer to advance goals they may have.
It is strange, this last couple of days, seemed like information about DOM has been popping around everywhere.
Then today in the morning i came across this on failblog http://cheezburger.com/7974345216 thought it was hilarious. I think that she got “DOMED” :P
Nice work, Chris! The only adjustment I might make is to the statement that the DOM corrects “mistakes” in HTML. While that can certainly happen, it might be more accurate to say that the DOM “polishes up” HTML; for example, closing list-item tags are not required in HTML5, and it’s perfectly valid to leave them out of your code, but the DOM will insert them when it parses the page. The same goes for quotes around attribute values. These aren’t “mistakes”, per se, so long as the developer is doing them consciously. (I know that you recommend against doing so, but I regard that as a stylistic difference, not a “right or wrong” battleground).
In the past I’ve contrasted the HTML and DOM in terms of cognition: HTML is the stored, “long term memory” of the page, while the DOM is “short-term memory”: momentary, ephemeral changes and impressions.
I have a short version: the DOM is the sum of what your browser has “in its mind” when it shows you a webpage.
The source, the scripts, the CSS, the images, the APIs, etc, all contribute to it.
Great explanation. Thanks Chris.
I’m not sure on how to explain this to someone without a computer science degree, but I’ll try my best: the DOM is what is abstractly known as a “data structure,” more specifically, a “[tree data-structure](https://en.wikipedia.org/wiki/Tree_(data_structure)).”
If you want to better understand on how to update the DOM, maybe you might want to look at a few examples on how to work with tree data structures, in general. Start with learning recursions, then move to writing your own linked-list, then move to trees. And as a challenge, try modifying the tree that you construct, e.g. creating, deleting, and updating nodes. Maybe, to really challenge yourself, convert a tree into a flat list. This requires what is called a “traversal.”
I wish I had come across this when I was trying to find a succinct/practical explanation of the DOM, excellent!
I’ve since found this rather useful too: http://domenlightenment.com/
Excellent post & Link..!
Taken. ;-) In fact, you did, I guess:
In HTML 4, the tbody element is required but the start and end tags are not. This means the tbody element is always there in a table whether you have its start and end tags in the code or not.
You cannot leave out the tbody element. You could leave out the tags since both are optional (the Os in the DTD line
<!ELEMENT TBODY O O (TR)+ -- table body -->).
This means that tr elements are never children of table elements, but their grandchildren, even if there’s no other tag between
<tr>in the code.
Different story in XHTML 1 where there are no optional tags. In order to be compatible with HTML 4, coders must have been given the choise to include tbody tags or to leave them out. Therefore tr elements are allowed as children of table elements, the tbody element is not required.
A XHTML 1 document with no tbody tags, processed as XML (
application/xhtml+xmlor similar media type) will generate a DOM where tr elements are children of the table element.
Whereas when processed as HTML (
text/html), the HTML 4 rules apply. This means that the DOM generated from the same XHTML 1 source differs depending on the media type. This is rather problematic than desired. Best practice is to always use tbody tags in XHTML 1.
In HTML5, the content model of the table element includes “either zero or more tbody elements or one or more tr elements”, i.e. the tbody element is not required in HTML5 speech.
But even without tbody tags, the HTML5 parser will generate a tbody node in the DOM, mimicking the same behavior as in HTML 4.
Important clarification. The distinction could be important if you were using CSS direct-child rules for styling; depending on which parser interprets the materials rules may not get applied. Best be on the same side and always use generic descendent rules when talking about tables…
Good artical Chris and nice to see and read some of the various responses. I visit your site on occasion and find alot of inspiration and to me a heck of a resource.
Keep up the good work.
Could we get a link on that owl demo ?
The answer to this question really sunk in to me just the other week when I was trying to figure out “why Modernizr wasn’t working”. At that point, it WAS working — but the classes it adds doesn’t show up in “view source” — only in the browser’s inspector. THEN I realized. There lies all the difference.
It’s funny how long I’ve been doing web stuff and how I still didn’t grasp little things like this. I guess it’s not uncommon, though; a lot of websites give you a lot of different kinds of explanations. Thanks for the visuals.
I agree with Jessica above, I never thought about little things like this about DOM, been playing around with DOM for years. Makes me wanna ask a question about DOM to the next developer I interview :-)