HTML, CSS & the Browser

The DOM

Definition

When a page loads, the browser parses the HTML and creates one node per element, plus nodes for text and comments, arranged in a tree that mirrors the nesting in the file. That tree is the DOM, and it is reachable from JavaScript through the document object: document.querySelector finds a node, textContent reads or replaces its text, and appendChild adds a new one. Every node knows its parent, its children and its siblings. The important distinction is that the DOM is not the file. The file is a fixed string of characters; the DOM is a living structure that scripts rewrite, that the browser repairs where the markup was malformed, and that reflects the page as it is right now rather than as it was delivered.

Why It Matters

That gap between file and tree explains a whole class of confusion. View source shows what the server sent; the Elements panel shows the current DOM, and on a page built by a framework the two look nothing alike — the source may be a body containing a single empty div. If a search engine reports your page as blank, or a rule is failing on an element you cannot find in the source, that is the first thing to establish. It also matters for cost: every change to the DOM can force the browser to recompute layout, so a script that adds a thousand rows one at a time is visibly slower than one that builds them off-tree and inserts once.

How It Works

Parsing runs top to bottom, building nodes as it goes, and a script encountered without defer or async pauses it at that point. A script that runs before the element it targets exists gets null back from querySelector, which is the reason for the classic error about reading a property of null — the fix is a defer attribute on the script or a DOMContentLoaded listener. Once the page is loaded, any change to the tree triggers a recalculation of styles and, if geometry changed, a reflow of the layout. The Elements panel in developer tools shows the live tree, and the difference between it and view source is exactly what scripts have done since the page arrived.

Real-World Example

Someone exports an AI-built dashboard and publishes it at sales-board.99helpers.site, then notices that the search preview shows no text at all. View source is a head, one empty div and a script; every row is written into the DOM after load by client-side rendering. The page is fine for visitors and invisible to a crawler that does not run scripts. Adding the headline figures as real markup in the HTML, with the script enhancing them afterwards, gives both audiences something to read.

Common Mistakes

  • Running a script in the head that looks for an element further down the page — the node does not exist yet, so querySelector returns null and the script stops there
  • Assuming view source and the Elements panel agree — after a script has run they routinely do not, and only one of them shows what the browser is actually working with
  • Rebuilding a large list node by node in a loop — each insertion can force a reflow, where building the whole fragment first and inserting once does not

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →