A Brief Introduction to the Document object and DOM
Sometimes, I get lost while working on code. Not lost in the ‘hitting the wave where lines are just flowing out my fingertips’ kind-of-way, lost like I can feel my fight or flight instincts kicking in. It is an unfortunate feeling that makes me nostalgic for my halcyon days of Dreamweaver and Xanga in the early aughts. While thinking about those times without centralized web-design ethos, clunky applications, and the ubiquity of t9 can be fun, it does not change the reality that I am still lost and the only way shed that feeling is to work and locate myself within the code.
Succinctly put, the document is the file that a programmer is manipulating to create content and functionality on a website. It is a representation of how the website will appear once loaded by the browser and is often a HTML or XML file type. The document is also taking a step towards an object-oriented approach to program as it is also an object with inherited traits, and is connects to other objects. Before we get ahead of ourselves, let’s look at the document in its platonic state.
Here I have a blank html file pulled up on visual studio code (VSCode). There are no inputs, no interface, just peace. What does this blank document look like when loaded by the browser? Let’s see..
Unsurprisingly, we are faced with — a blank document. What is intriguing is that when we log document to the console we see that regardless if we specified or not the document is defined and has a basic shape — the simplest of HTML boilerplate code:
A html tag with two children tags of head and body. Our browser is giving us a little help here forming out our blank HTML into something it can process.
We can represent this rudimentary code environment in a tree structure utilizing the helpful tools at https://software.hixie.ch/utilities/js/live-dom-viewer/:
So here we are getting a semblance of the bare context we are working in — an HTML canvas that we can imbue with form. Within our HTML document we have the tags of <head> and <body> that serve as further subcontexts to the overarching context of the document. Within these tags are information: in the <head> tag we provide information about our website such as its title, scripts and stylesheets (both local and throughout the web), and in a bygone era, full scripts and styles were placed within the <head> to dictate the look and behavior of content within the site. To put it plainly the <head> tag holds metadata. The <body> tag is where we dictate the content for the site and makes for further nested structures of tags.
As mentioned earlier, the document is also an object. It has inherited methods and properties available to it that enable it to function for our purposes. To better visualize where the document is, we can utilize chrome developer tools’ neat feature of highlighting context when we type properties into the console.
I’ll start with document.
We see that everything is highlighted blue. Next, let’s look at the head by calling the head property on document: document.head
Now, even though, the console shows that head is selected but nothing appears. We can surmise that this is because the head tag does not dictate visible content on the site so should not take up any real estate on the webpage.
Lastly, I will specify the key of body on the document: document.body
we see that the blue is highlighted but we also have a pastel orange border around the blue. This border is a default styling of the body property that chrome developer tools makes visible to us. The default styling here is that the body has a margin of 8 pixels.
While We were just looking to locate ourselves within the code, even at this snail’s pace, we are raising more and more questions. The document is a file and an object? It has inherited properties? It has children which also have inherited properties?
Before we get lost in these weeds, we need to remember sometimes to really know where you are you must go out and slowly drill your way back to your specific location. Take, for example, a tourist was bumbling along Canal street in New Orleans and approached you for directions. If you replied North America, the tourist would likely not be in an any better state and probably would take the response as an insult. This is all to say a bare understanding of the document is not enough, we need more context to understand where we are and how the document is used in practice. A good starting place is the DOM.
A nice primer for understanding the DOM is this article by Kara Luton who also crafted the nifty and clear DOM tree we see above.
So in describing the DOM, I mentioned it was an API. This is another topic that reaches outside of the scope of the locating yourself within the document but it is worth spending a moment on, in order to better understand the DOM.
API stands for Application Programming Interface. They are intermediaries for a multitude of processes that take place on the digital space. A way to visualize how they work is to think of the phone switchboard operators from the late 19th to early 20th century who took calls and physically put phone plugs in the appropriate jack to facilitate the telephone call reaching its intended destination. APIs automate process and distribute requests and data in similar way metaphorically, if not literally.
The DOM is an API thus it serves as an in-between allowing the developers to interact with elements on the document without actually interfacing with the code in the HTML. When we accessed the tags earlier we were getting a sneak peak at what the DOM could do. We pulled up those nodes and could access their information even as they were empty.
Nodes are a foundational aspect to the DOM API and the DOM tree. Simply put, nodes are a representation of the boxes that all the content of the webpage consists of. Nodes are interconnected and connect out the Global Window Object and allow for the functionality of our site.
Putting It Together
So we have gone on a little journey into the context that we are working within but the only true way to exercise your proprioceptive muscles is to stretch out and experiment within the environment. We can’t look at a blank page all day, let’s make a little HTML site.
So with a small amount of HTML we have a site inside our document. Let’s use some document methods to touch our content. I will start off with getElementByClassName.
Another document is getElementById which works similarly to getElementsByClassName but works with Ids. I recommend searching the MDN documentation for document methods because as the document is the base level there are a lot of ways to interact with it.
Another way to manipulate the DOM is to use jQuery which is a library you can import into your HTML document. jQuery’s $ function makes it easy to introduce, alter, and remove elements all using the built-in functions.
Let’s write some simple code and add a artist’s image to our webpage.
So I have left the index.html file and am inside my index.js file which is connected to the html inside the html’s <head> tag.
Within this code I am assigning a new variable $body to document.body using the jQuery ($) function. Then I proceed to create a div and image using the same method. Next, I can set classes and attributes to my elements by using the built in jQuery methods. Finally, I append the image to the $profileDiv which is to make it the last child of it and I prepend the $body with the $profileDiv allowing the $profileDiv to be the first child of the $body element.
This is what that looks like on the site.
I have given the profile image the class ‘profile’ and I use the document.getElementByClassName and even though we did not code in HTML we get the correct element. That is the DOM at work.
Let us check out out DOM tree once more:
That’s quite a lot for such a rudimentary website. You can see where as code grows more and more where someone could find themselves lost. But taking it step by step is how you get to finding where you are and more importantly, where you are going.
I hope this foray into the basics of basics in web development was interesting, reading and thinking on this topic certainly was for me. Infrastructures on the web are ever-growing and our world continues to interface it in evolving ways. It definitely is impossible to truly know where you are in this four-dimensional, non-Euclidean, web space. Additionally, the document is just one place you could be coding and even it is spread out into different nodes that can be further spread out and specialized. It can be overwhelming but it’s important to remember to take some time and ask: what am I doing, why am I doing it, and where is this action taking place? It calms me down at least.