Hi 👋
This article will talk about the DOM. This is the second article in the series.
DOM tree.
DOM(Document Object Model) is a software interface for HTML, XML and SVG documents. It provides a structured view of the document(tree) as a group of nodes and objects that have properties and methods, and defines the way in which the structure can be accessed by the program.
DOM binds web pages to scripts or programming languages.
The basis of an HTML document is tags.
According to the DOM, an HTML tag is an object and nested tags are its "children".
All objects are available with JavaScript, we can use them to modify the page.
For example, document.body is an object for the <body> tag.
REMARK
JavaScript is not part of DOM, even though it(JS) is most commonly used.
DOM example.
This is a typical HTML page:
<!DOCTYPE HTML>
<html>
<head>
<title>About DOM</title>
</head>
<body>
DOM...
</body>
</html>
And this is a view of an HTML document as a tag tree:
html
head
#text
title
#text "About DOM"
#text
#text
body
#text "DOM..."
Tags are node elements(elements). They form the structure of the tree: <html> is the root node, <head> and <body> its child nodes, etc.
Text inside the elements forms text nodes named #text. The text node contains only a string of text. It cannot have descendants (it is always at the lowest level).
Spaces and line breaks are also symbols. Like letters and numbers, they form text nodes and become part of the DOM tree.
REMARK
- Spaces and line breaks before the
<head>tag are ignored;- There are no characters after
</body>tag. Anything written after this tag is moved to the end of the<body>tag according to the DOM specification;- Everything written before
<head>tag is moved inside<body>.
Everything written in HTML is also in the DOM tree, even comments.
Remark
Comments is also a DOM tree node.
In this example, there are no text nodes created by spaces and line breaks:
<!DOCTYPE HTML>
<html><head><title>About DOM</title></head><body>DOM...</body></html>
REMARK
One of the reasons why minimized(single-line) code works faster.
Building a DOM.
When building a DOM, the browser automatically fixes incorrectly written HTML. For example, if a file contains only the word world, the browser will add all the necessary tags. The DOM will look like this:
html
head
body
#text "world"
REMARK
For short, I don't take text nodes from spaces and line breaks into account.REMARK
Also the browser closes all unclosed tags. But I strongly recommend closing them.
Other nodes.
There are 12 DOM nodes:
- ELEMENT_NODE
- ATTRIBUTE_NODE
- TEXT_NODE
- CDATA_SECTION_NODE
- ENTITY_REFERENCE_NODE
- ENTITY_NODE
- PROCESSING_INSTRUCTION_NODE
- COMMENT_NODE
- DOCUMENT_NODE
- DOCUMENT_TYPE_NODE
- DOCUMENT_FRAGMENT_NODE
- NOTATION_NODE
But most often only 4 of them are used: document, elements, text nodes, comments.
Here - you can see the DOM model in real time.
In the next article I will talk about shadow and virtual DOM. Don't miss it!
Afterword.
Thank you very much for your attention. I hope it was useful for you 🙏
Follow me, it makes me write new articles 😌
I'd be happy for your feedback.
C u! 😉
Oldest comments (9)
I am mostly a backend developer who works with frontend guys and this stuff has always fascinated me and most of the time left me confused, I guess this series will be really helpful for folks like me.
Glad to hear it.
I'll do my best!
DOM manipulation is what javascript was created for. It's very fun and actually super intuitive. Don't let these messes of new JS frameworks scare you away. Using javascript in the browser is simple and powerful.
Maybe you could create a Part 2 where you a bigger deep-dive into how DOM nodes are constructed behind the scenes in the underlying C/C++ code of the web browser (e.g. the data structures used by the web browser). I feel like most people don't understand how the DOM works because they don't have a solid understanding of the fundamentals of data structures, memory allocation, etc. People just take for granted that the browser works but someone had to design the data structure for an Element node, etc.
Here's a little history behind why tags are automatically closed: Early web browsers started allowing unclosed tags and other oddities that deviated from the early Standards mostly because Internet Explorer started aggressively doing so. Microsoft saw that some developers were not closing their tags and decided to add in some logic so visitors to websites using IE wouldn't see "broken" layouts. For tag elements, depending on the current open DOM tree tags, the browser uses a number of rules to determine what other tags to "close" before inserting the new node (e.g. encountering a
<tr>inside a<td>will "close" the current table cell AND table row and then start a new one). This and a few other things led to the early web browser wars where IE took a commanding lead for many years. Microsoft would do something and everyone else would have to play catch-up. A side-effect of allowing broken HTML happened: A number of developers then decided it was okay to be lazy and not close tags more frequently - their HTML worked fine in some browsers but not others. Web browsers did different things depending on how tags were structured in the HTML document. That eventually fueled a whole "W3C validation" movement that included showing "W3C validated" badges on pages that visitors didn't care about but apparently developers did. That movement eventually died off as developers stopped caring as much because they couldn't do much about it due to web browsers being mostly closed-source affairs (pre-Firefox!). Most people today just care if something displays correctly in the major browsers rather than being strictly Standards-compliant nor really understanding why the browser does things the way it does.By the way, "closing" a tag isn't really what you probably think it is. It is instructing the browser to move a pointer to the current node back up the tree it is building in order to append a new child nodes. A 'tr' tag inside a 'td' tag doesn't make sense but the 'td' is probably inside its own 'tr' tag which is inside a 'table' tag. So using that knowledge, it is possible to move the pointer to a more logical location to start the new 'tr' tag. But that extra work costs CPU cycles. It is better to just have valid HTML in the first place and not rely on side-effects of history to correct the mistakes. This also explains why void tags like
<img>don't have a matching</img>tag - there's nothing there to do as the pointer for where to insert the next node is in the correct place already.First, if I could like your comment like a million times trust me I will.
Second from your comment:
Most "modern frontend developers" (at least the ones that are vocal online) will likely frown on any frontend developer that says: I want to learn algorithms and data structure. And some will argue with you that "What is the necessity of knowing data structures as a frontend developer?"
With the following comment, I am glad it is changing:
Currently, I’m trying to learn about data structures. I’ve been working four years. I’m still not good at algorithms and data structures.
And this:
Every time I tell someone I would like to learn them they look at me very strange: in my eyes this is a sign they're serious business :).
Then this:
Same here bro, I also want to refresh in data structures and algorithms, when I started working as a dev, I already forgot to practice/using it in some situations because of using frameworks and libraries in development, etc.
Then you said this:
Big time.
Finally, thank you for the history lesson. I learned a lot.
As a closing note you said this:
If the author is not chanced to write about it. Please, do. I'll be glad to read it.
Have a nice day.
Okay, maybe I'll write about it.
The way the browser works from the inside is not quite about web development.
Of course, this is very valuable knowledge, but the presence or absence of this knowledge will not affect the quality of web applications. It is enough to understand the basic concept, not what is happening under the hood.
To drive well - you don't have to know exactly how every part of the car works. There's a lot of examples.
If the developer doesn't know what's going on under the hood of the browser, that doesn't make him a bad developer. Same as if developer knows it doesn't make him a good.
People are different, someone is interested in one thing and someone else in another.
But if it is you (or someone else) who is really interested, I will write an article about it soon.
Microsoft is by no means the evil corporation as you expose it.
In the mid-1990s, all browser companies planned to release each version of their HTML language with their own tag names.
HTML standardization happened in 1996, and the "W3C validated" badges appeared after 1997 and had no effect on the browser war.
IE’s market leadership and the collapse of Netscape is only due to dumping, not Maicrosoft’s desire to please lazy developers. The appearance of "open" Firefox did not affect the standardization of HTML, but only gave impetus to the emergence of new browsers (Opera, Google Chrome) that surpassed IE in functionality. After all, even now, with "open" browsers, the complete matching of tags and HTML attributes, unfortunately, could not be achieved.
There are many tools to help make the project cross-browser.
Again, in order to create a quality application, it's enough to know about it and take it into account during development.
I know how browsers work and how DOM is built, but the only place I have applied that knowledge is this comment. It's very useful to know, but it's not necessary.
I assure you, I'm thinking right about closing the tags.![]()
element cannot have child nodes, it is defined as empty and the final tag is forbidden (as it is not reasonable).
Historically, HTML was based on SGML, which allows you to skip tags under certain conditions.
Since the
Thank you for your feedback ❤️
Have a good day!
They will do when they need tree-shaking performance from the main front end frameworks. There is a very subtle but important distinction between the DOM and the rendered page; being able to separate the two concepts is one of the markers for being a 'professional' front end dev IMHO
Good job. Nice introduction!