Session 7: The DOM

Your HTML file is text. When the browser reads it, it builds a live tree of objects in memory representing that structure — the Document Object Model — and it is this tree, not the file, that JavaScript works with. Change the tree and the page changes; the file on disk is untouched.

That distinction explains a great deal. Viewing the page source shows the original file, while the Elements panel in developer tools shows the current DOM — and after your JavaScript has run, they are different. When something appears on the page but is not in the source, this is why, and knowing where to look saves a lot of confusion.

Then the practical consequence: the DOM must exist before you can select from it. A script that runs before the elements are parsed finds nothing, which is why `defer` matters. And the DOM is live — you can add, remove and rearrange elements at any time, which is what makes a page an application rather than a document.

Two methods cover almost everything. `querySelector` takes any CSS selector and returns the first match — `document.querySelector('.card')`, `document.querySelector('#submit')`, `document.querySelector('nav a')`. `querySelectorAll` returns every match as a list. Because they take CSS selectors, everything you already know about CSS applies, and there is one less syntax to learn.

The older methods still exist — `getElementById`, `getElementsByClassName` — and you will see them in older code. They work, but `querySelector` is more flexible and consistent, so there is no reason to prefer them in new code. The one difference worth knowing is that `querySelectorAll` returns a static list: it does not update when the page changes, which occasionally surprises people.

Then the habit that prevents a whole class of bugs: check what you got. `querySelector` returns `null` when nothing matches, and the next line — `element.textContent = …` — then throws 'cannot set property of null'. That error means one thing: the selector did not match. Log the selector, look at the actual markup, and you will find a typo, a missing class, or a script running too early.

`textContent` sets the text inside an element, treating everything as plain text. `innerHTML` parses what you give it as HTML, which is more powerful and considerably more dangerous. The difference matters enormously: `innerHTML` with data from a user will execute markup, and that is how cross-site scripting happens — the single most common serious web vulnerability.

So the rule is simple and absolute: use `textContent` for anything that came from a person, and reserve `innerHTML` for markup you wrote yourself in the source file. A comment, a name, a search term — all of it goes in with `textContent`. If a user can type `<img src=x onerror=…>` into a field and it lands in `innerHTML`, it runs.

Then the other properties you will need. `value` reads and writes what is in a form input — note that an input's value is not in `textContent`. `setAttribute` and the `dataset` API handle attributes and `data-*` values. And `classList` — `add`, `remove`, `toggle` — is how you change classes, which is almost always better than setting styles directly.

There are two ways to change appearance from JavaScript, and one of them is usually wrong. `element.style.color = 'red'` writes an inline style, which has very high specificity — it overrides your stylesheet and becomes difficult to undo later. Sprinkling inline styles through JavaScript produces a page whose appearance is scattered across two places and impossible to reason about.

The better way is `classList`: define a class in your CSS — `.is-hidden { display: none; }` — and toggle it from JavaScript. `el.classList.toggle('is-hidden')` keeps the styling in the stylesheet where it belongs, keeps the JavaScript to a single concern, and makes the state inspectable in the DOM. This is the standard pattern and it scales; inline styles do not.

Then measure before you change. Reading a property like `offsetHeight` or `getBoundingClientRect()` gives you the real rendered size, which is how you respond to layout rather than guessing. And remember that changing the DOM has a cost: making a hundred separate changes in a loop is far slower than building the markup once and inserting it, which matters when a page has a long list.

An event listener attaches a function to an element and an event type: `el.addEventListener('click', handler)`. The critical detail is that you pass the function itself, not the result of calling it — `handleClick`, never `handleClick()`. The parentheses run it immediately and pass its return value, so the listener never fires. Everyone makes this mistake once.

The handler receives an event object with useful information: `event.target` is the element actually acted on, `event.preventDefault()` stops the browser's default behaviour (essential on forms and links), and `event.currentTarget` is the element the listener is attached to. Knowing the difference between target and currentTarget is what makes delegation work.

Then removal and delegation. `removeEventListener` needs the same function reference you added, which means an anonymous function cannot be removed — so name your handlers if you will ever detach them. And delegation — one listener on a parent handling events from children via `event.target` — is how you deal with lists whose items are added and removed, because it does not care whether the item existed when the listener was attached.