Learning on Web Dev Open is free for all.

Take It Apart > The DOM as an APIThe DOM is not your HTML
Phase 01The DOM as an API67 of 434

The DOM is not your HTML

Your file is the seed. The DOM is the living thing, and by the time a user interacts with it the two have diverged.

Concept16 minAI pair

You wrote an HTML file. The browser parsed it into a tree. Then your CSS styled the tree, your JavaScript changed the tree, the user typed into the tree, and a framework replaced half of it. What is on screen now is a function of the tree, and the file has not changed since the first millisecond.

The clearest demonstration takes ten seconds. Load a page, type something into an input, then choose "View Source". Your typing is not there, view-source shows the bytes the server sent. Now open the Elements panel and look at the same input: still shows value="…" from the markup, because the attribute never changed. But run document.querySelector('input').value in the console and you get what you typed. Three views, three different answers, all correct.

That is the attribute-versus-property distinction and it matters in real code. The attribute is the initial value, in the markup. The property is the current value, on the DOM object. For value they diverge the moment the user types. For checked the same. For class there are two views of it, className as a string and classList as an object with add, remove and toggle, which is the one you want. For data-* attributes, the dataset object gives you the same thing more conveniently.

Some attributes and properties do stay in sync, id, href, src, which is exactly why the ones that do not are confusing. There is no rule you can derive; it is specified per attribute. What you need is the awareness that they are two different things, so that when getAttribute and the property disagree you recognise the situation instead of concluding the browser is broken.

This also explains something you will meet properly in Phase 04. Server-rendered HTML arrives as markup, and then a framework has to attach its own event listeners and state to the already-existing tree rather than building a new one. That process is hydration, and every bug in it is a version of "the DOM the server described and the DOM the client expected are not the same tree". Knowing that the file and the tree are different objects is the whole prerequisite.

Practical habit from this chapter: when you are debugging, the Elements panel is the truth about structure, the console is the truth about values, and view-source is only the truth about what the server sent. Reaching for the wrong one of those three is a surprisingly common way to lose an afternoon.

You should now be able to

  • Explain the relationship between source, DOM and rendered output
  • Tell an attribute from a property and know when they diverge
  • Use the Elements panel as a live view rather than a source view
  • Say what "hydration" is fixing, before you meet it in Phase 04
Ask the community

Loading…