By the end of the lesson, you can explain what the DOM is and how it differs from the HTML source sent by the server, you can draw the document tree of a short HTML fragment, and you understand why it matters that an element expresses its meaning, not just its look.
Why is the HTML text not enough?
The server sends HTML text. For a program (the browser, CSS, JavaScript, the screen reader) to work with it, it must see it not as a sequence of characters but as a structured model: what contains what, which element is the child of which. The model built from the text is the DOM: the tree-shaped, programmatically accessible and modifiable model of the document in the browser's memory.
The HTML source becomes a document tree
The browser parses the received text and builds a tree of nested nodes. The root is the document, below it the html, then the head and the body, then the content elements.
<main><article><h1>Course enrolment has opened</h1><p>Enrolment is open until Friday.</p><ahref="/courses">Courses</a></article></main>
flowchart TB
D[Document] --> M[main]
M --> A[article]
A --> H[h1]
A --> P[p]
A --> L[a]
The diagram shows the parent–child relationships of the main elements. The real DOM also contains text nodes and further details: the text "Course enrolment has opened", for example, is a separate text node as the child of the h1 element.
The tree is not another HTML file: it is a live model. HTML parsing creates it, JavaScript can modify it later, and CSS applies to the elements of the tree. The parent–child relationship matters to CSS and JavaScript too: a style rule can target, for example, all paragraphs under an article, and JavaScript can find an element and change its content. According to MDN, the DOM lets a program change the structure, style, and content of the document.
The source and the current DOM
The HTML source received from the server and the browser's current DOM are not always the same:
The browser interprets faulty or incomplete HTML by correcting it according to the rules of the standard.
JavaScript can insert a new element, replace text, or remove an element.
On the course page, for example, a status indicator initially says: "No course selected". After the user's choice, JavaScript rewrites this in the DOM: "Web Programming 1 selected". The source file sent by the server does not change because of this. "View source" and the Elements (Inspector) view of the developer tools can therefore show different content: the former shows the text that arrived, the latter the current model.
flowchart LR
S["HTML source (from the server)"] -->|parsing| D["DOM (in memory)"]
J[JavaScript] -->|modifies| D
D -->|rendering| K[Screen]
A semantic element says more than the look
h1 marks a main heading, p a paragraph, a a link, main is the main content region, article is a self-contained unit of content. Choosing an element is therefore not merely a visual decision: a text does not become a heading because it is displayed in large letters, but because it is a heading in the HTML. Screen readers, search engines, and other programs rely on this structure. This is called semantic HTML: the elements express their meaning.
Structure and hierarchy
Headings (h1–h6) give a hierarchy: under a main heading, subheadings structure the content.
The text of a link should be understandable on its own; "click here" does not say where it leads.
The labels of form fields (label) say what data the field expects.
All of these serve to make the meaning of the content readable, not just its look.
The Elements view of the developer tools
The Elements (in Firefox, Inspector) view of the browser's developer tools shows the current document tree: when you select an element, you can see its place in the tree, its attributes, and the styles that apply to it. The Network panel, by contrast, shows what resource arrived. Together the two views help decide whether a text was in the server's response or was built after loading. (This is an inference, not complete proof of the internal workings, but a good starting point.)
Worked example: the course news in Kurzuspont
On the course news page, the server sends the article element with a heading, text, and a link. Afterwards JavaScript inserts a "New course available" notification at the top of the page. We observe the following:
View
What does it show?
View source
Only the article, without the notification
Elements view
The article and the later inserted notification as well
Screen
Both, according to the styles
The lesson: a search robot or a screen reader does not necessarily see content that JavaScript inserted later. This is why it is worth placing the important content already in the server's response.
Common misconceptions
Statement
Clarification
"The DOM is the same file the server sent."
The DOM is the browser's current, changeable internal model.
"Large text is automatically a heading."
Visual size does not replace the appropriate element.
"Every clickable element is a button."
The semantics and keyboard behavior of a native button are a separate property.
"The source and the Elements view are always identical."
Processing and JavaScript can make them differ.
"Semantic HTML only matters to search engines."
It matters to every program that interprets the page, including assistive technologies.
In brief
The DOM is the tree-shaped document model living in the browser's memory, created by HTML parsing.
JavaScript can modify it, so the DOM can differ from the source sent by the server.
Semantic elements express meaning, not just look.
The important content should preferably not depend only on later JavaScript.
Review questions
Draw the tree: <ul><li>One</li><li>Two</li></ul>!
Why can "View source" and the Elements view differ?
Why is a button element better than a div styled as a button?
Document structure and the DOM
Objectives
By the end of the lesson, you can explain what the DOM is and how it differs from the HTML source sent by the server, you can draw the document tree of a short HTML fragment, and you understand why it matters that an element expresses its meaning, not just its look.
Why is the HTML text not enough?
The server sends HTML text. For a program (the browser, CSS, JavaScript, the screen reader) to work with it, it must see it not as a sequence of characters but as a structured model: what contains what, which element is the child of which. The model built from the text is the DOM: the tree-shaped, programmatically accessible and modifiable model of the document in the browser's memory.
The HTML source becomes a document tree
The browser parses the received text and builds a tree of nested nodes. The root is the document, below it the
html, then theheadand thebody, then the content elements.<main> <article> <h1>Course enrolment has opened</h1> <p>Enrolment is open until Friday.</p> <a href="/courses">Courses</a> </article> </main>flowchart TB D[Document] --> M[main] M --> A[article] A --> H[h1] A --> P[p] A --> L[a]The diagram shows the parent–child relationships of the main elements. The real DOM also contains text nodes and further details: the text "Course enrolment has opened", for example, is a separate text node as the child of the
h1element.The tree is not another HTML file: it is a live model. HTML parsing creates it, JavaScript can modify it later, and CSS applies to the elements of the tree. The parent–child relationship matters to CSS and JavaScript too: a style rule can target, for example, all paragraphs under an
article, and JavaScript can find an element and change its content. According to MDN, the DOM lets a program change the structure, style, and content of the document.The source and the current DOM
The HTML source received from the server and the browser's current DOM are not always the same:
On the course page, for example, a status indicator initially says: "No course selected". After the user's choice, JavaScript rewrites this in the DOM: "Web Programming 1 selected". The source file sent by the server does not change because of this. "View source" and the Elements (Inspector) view of the developer tools can therefore show different content: the former shows the text that arrived, the latter the current model.
flowchart LR S["HTML source (from the server)"] -->|parsing| D["DOM (in memory)"] J[JavaScript] -->|modifies| D D -->|rendering| K[Screen]A semantic element says more than the look
h1marks a main heading,pa paragraph,aa link,mainis the main content region,articleis a self-contained unit of content. Choosing an element is therefore not merely a visual decision: a text does not become a heading because it is displayed in large letters, but because it is a heading in the HTML. Screen readers, search engines, and other programs rely on this structure. This is called semantic HTML: the elements express their meaning.Structure and hierarchy
All of these serve to make the meaning of the content readable, not just its look.
The Elements view of the developer tools
The Elements (in Firefox, Inspector) view of the browser's developer tools shows the current document tree: when you select an element, you can see its place in the tree, its attributes, and the styles that apply to it. The Network panel, by contrast, shows what resource arrived. Together the two views help decide whether a text was in the server's response or was built after loading. (This is an inference, not complete proof of the internal workings, but a good starting point.)
Worked example: the course news in Kurzuspont
On the course news page, the server sends the
articleelement with a heading, text, and a link. Afterwards JavaScript inserts a "New course available" notification at the top of the page. We observe the following:article, without the notificationarticleand the later inserted notification as wellThe lesson: a search robot or a screen reader does not necessarily see content that JavaScript inserted later. This is why it is worth placing the important content already in the server's response.
Common misconceptions
In brief
Review questions
<ul><li>One</li><li>Two</li></ul>!buttonelement better than adivstyled as a button?Learning resources