HTML vs. DOM | Marie Explains the Web
Learn how browsers use the HyperText Markup Language (HTML) and the Document Object Model (DOM) standards to turn text files into beautiful web sites.
December 20, 2020 • 3402 words • 12 minute read
This blog is a transcript of the YouTube video.
If you work on front-end web development, you’ve probably heard the terms “HTML” and “the DOM.” But what do they mean? Are they describing the same thing? How do they interact?
Join me to learn how browsers use the HyperText Markup Language (HTML) and the Document Object Model (DOM) standards to turn text files into beautiful web sites.
Hi, my name is Marie Chatfield Rivas, and I am a senior software engineer with a passion for front-end web development. Thank you so much for joining me today! We are going to talk all about HTML versus the DOM.
These are two terms that you may have heard around in web development, and they’re often used somewhat interchangeably or very related to each other. So you may be wondering, are they the same thing? Are they different? How do they interact? And what do I need to know in order to build websites and do other front-end development?
HyperText Markup Language (HTML)
So let’s go ahead and get started with HTML, in other words HyperText Markup Language. HTML is a text language that marks up content with structure and meaning.
And what I mean by that is that, say for example you know that the content that you care about is this text that says, “Pick your party style!” and then a list of different types of parties that you might like to go to.
Well, how would you communicate that to a browser?
You could just put a text file that just has the actual text content that you want to display. But this really doesn’t say anything.
We know that we want a list, but there’s nothing in this structure, this just plain texts that indicates that. That’s where HTML comes into play.
So we’re able to mark up our content and give it some structure, say how things are related, as well as give it more meaning.
So for example, we have these
<ul>, or unordered list, tag that then has children. That’s the structure bit. And each of those children is a list element the
<li> tags that has some content inside of it.
So we know that there are supposed to be three elements in our list that each has some text content. We know how they’re related to each other. Then we know where it should fit into the rest of our page.
But this alone is not a full page.
Usually this kind of HTML is found within the rest of your content. So it’s going to be an entire page.
So we’re going to see that we start out with something like this
<html> element tag at the top of our HTML file, that is the parent of everything else. And usually we’re gonna start out with that
<head> element that includes some metadata and information about the page itself, like for example, the title.
Then we’ll move down to usually we’ll have a
<body> tag that’s describing more of the actual content of the page as a user would see it. Typically, it’s good practice to have a
<main> element or sort of the main content of your page. What’s unique to this page. So not necessarily navigation, but the actual unique stuff.
And then finally all the way down in there we will eventually get to the actual content that we wanted to display, in this case, our list of party styles.
And one thing that you may note is it all of this is hierarchical. So we start out with that
<html> top level tag and everything is a child of that element. And each of these element tags can have children, the children may be other HTML elements or it could just be plain text content.
But at the end of the day, this displays a lot more meaning and structure than just the plain text that we were looking at before. But this is still just a text file. You couldn’t exactly just send this to somebody and be like, “oh, hey, check out my webpage. Isn’t this really cool?” It’s got a lot of stuff in there.
So how does this become an actual webpage that looks the way that you expect? That’s where the DOM comes into play.
Document Object Model (DOM)
The DOM is the Document Object Model, and this is an API that describes how webpages work, and it’s implemented by browsers.
So when a browser gets an HTML text file it uses the DOM APIs in order to figure out how to parse that text file into this hierarchical data structure that we sometimes call the DOM tree, because it’s a tree data structure
We can see that the top level object is this document. And then it has children. It has nodes inside of it. And they all map to the same HTML elements that we see in our text file. So there’s an
<html> text element and that corresponds to the HTML DOM node. The
<body> HTML element becomes a body DOM node, et cetera, all the way down.
And then this is all internal data structure that the browser maintains and keeps up to date and keeps in sync. And it has a lot of extra properties and interesting behavior attached to each of these DOM nodes, everything that you need to make a webpage work.
So then the browser uses that internal DOM data structure, along with all the behavior that it represents, to actually render the webpage that you’re used to seeing and that your users can see and interact with.
So for example, if you’ve ever used the
document it might not actually be there. The
And there’s also a whole bunch of other stuff that these different APIs and standards implement and describe. It’s a really great idea if you have some time to go and start poking through them, reading through them. You’ll learn a whole bunch of stuff. And basically every single thing that happens on websites that you can write in a file and have it come to life, it’s described by one of these standards.
A Metaphor for HTML and the DOM
There’s a metaphor that I think is really helpful in terms of understanding how HTML and the DOM interact. So I like to think of HTML as house plans, like construction plans. So we can take this text HTML file, send that to a browser, and then the browser will read all of the standards and APIs around the DOM in order to figure out how to actually build a house from those construction plans.
And then in theory, if we send the exact same HTML text file to a different browser, it will reference those same APIs and standards in order to build a house that is pretty much the same.
We’re probably never gonna be exactly the same just because building a browser is incredibly complicated. These standards are massive and it’s very difficult to get them to consistently behave exactly the same way in every single scenario all of the time. So you may see some slight differences, but for the most part, these are gonna be the same house.
And then of course you have users interacting with your webpage, and as they cause events to happen, click on things, or do other stuff, usually the browser is going to interpret those with the DOM API and then make changes to the DOM as users are submitting forms or anything else.
Live Demo with Glitch
So why don’t we take a look at some code? I have here this lovely little Glitch app, and it has an HTML file, which looks really similar to the code that we were just looking at. We can see down here that we have this list and all of the elements.
So let’s go ahead and look at this in the new page. So this is what we would expect to see. If we view the page source, we’re gonna see that this is the exact same HTML file that we saw that the server was going to render. Let’s go ahead and see if we can take a look at the DOM.
So I’m gonna be doing all of this with the Chrome Developer tools, but pretty much all browsers have some way of accessing these developer tools. So here I can see a representation of my DOM tree. Once again, I see that I start out with this top level
<html> element. I’ve got the
<head> and the
<body> as described in my HTML file and what’s once again, these are all the DOM nodes. I can click all the way down and see my list elements.
document.children // HTMLCollection [html]
So for example, we can look at the children of the document object, and we see that it’s actually just this
<html> element that we defined in our HTML text file that has now been transformed into a Document Object Model. And we can keep interacting with this.
document.children.children // HTMLCollection(2) [head, body]
We can grab that
<html> element and look at its children, and then we’ll see the
<head> and the
<body>. And we can just keep doing this forever, or we can also use different DOM APIs to interact with those things directly.
document.querySelector('li') // <li>💃🏻 dance</li>
So for example, if you’ve ever done document.querySelector we can use this to use the CSS selector to grab an element out of the document, as long as it exists. So for example, I could say I want an element that matches the list element. And I’m just gonna grab the first one and then I can interact with this one.
There’s also a fun trick, by the way, at least in the Chrome Dev tools, not clear about other ones, but you can see here that if you have an element selected here in the DOM tree you can use
$0 in the console to refer to this element, which just means that right now
$0 is going to refer to my list element. And if I click something else
$0, it’ll refer to that one.
I can also assign these to variables so that I can access them later. Or you can always right click and store as a global variable. This is really helpful if you’re debugging just to have some quick access to things.
One interesting DOM API is the one that creates new elements. So if you are using something that is maybe React or Ember or Angular or Vue that’s doing some fancy rendering for you, they’re probably using this API under the hood in a way that you don’t have to write it yourself.
newLi = document.createElement('li') // <li></li>
So I can create a new list element, and I’m just gonna call that document. And it has a function called createElement. And then I tell it the tag name that I want. In this case, just another list element.
newLi.textContent = 'hello world' // 'hello world'
And then on this element I can now, let’s say set the text content to be hello world. Now this doesn’t actually exist anywhere in the DOM yet. I just have a reference to this element, but I can add it to the DOM.
$0.appendChild(newLi) // <li>hello world</li>
So if I have my, oops, I have my unordered list, I can append the child, pass it my new list element. My DOM tree has been updated with the object that I just created.
But if we view the page source, this HTML file is still unchanged. This doesn’t necessarily stay in sync with the DOM. This is the text file that the browser used to create the initial version of this, but then the DOM tree does change over time. And that’s totally fine.
There’s a whole bunch of other fun things that you can do with the DOM API. Pretty much all events, interaction, it is what, for example is describing a list element typically has this little bullet and has some indentation and all of this other amazing stuff.
And then in general, I would just say that the MDN Web Docs are a fantastic, they’re my go to documentation website. So if you do wanna look a little bit more into what properties and functions you can call on DOM nodes, this is a great place to go.
Thank you so much for joining me today. I hope that that has given you a little bit more insight into exactly how HTML and the Document Object Model interact with each other in webpages.
So check back another time and see if I’ve managed to create that video. And in the meantime, if you look below, there should be links to all of the resources that I have used today including the MDN Docs and the Glitch app that I was just demoing. Thank you so much and have a great day.