The previous lesson ended with a semantic index.html and with the feeling that reaching an element by hopping from firstElementChild to nextElementSibling is awkward and fragile. It is. The real way of working with the DOM consists of describing what you are looking for with a CSS selector and letting the browser find it for you, and then changing it: its text, its attributes, its classes. In this lesson you will learn both halves of that job, along with the judgment calls that separate professional code from code that works by accident: why textContent is the default option and innerHTML a security risk, why an attribute and a property with the same name may not hold the same value, why changing a class is always better than touching style, and why reading the width of an element can be surprisingly expensive. By the end, the tasks on your page will show the real status and priority coming out of the Board.

1. CSS selectors as a common language
2. The classic methods: getElementById and friends
3. querySelector and querySelectorAll
4. Comparison table of the selection methods
5. Searching inside an element: the scope of the search
6. closest() and matches()
7. From NodeList to array
8. textContent, innerText and innerHTML
9. Attributes versus properties
10. dataset and the data-* attributes
11. Classes with classList
12. Inline styles with style (and why hardly ever)
13. Reading geometry: getBoundingClientRect and offsetWidth
14. Nómada Tasks: painting status and priority
15. Common Mistakes and Tips
16. Exercises
17. Conclusion

A CSS selector is an expression that describes a set of elements. You know them from the CSS you wrote in the previous lesson; what matters now is that the same language works for searching from JavaScript. A quick review of the ones you will use most:

The fact that selectors compose is what makes them powerful. #task-list > li.task--high:not(.task--done) describes, in one line, "the direct children of the list that are high-priority tasks and are not done". Writing that by navigating the tree by hand would be ten lines.

Before selectors existed in JavaScript there were three methods, and they are still in use:

Three details to keep in mind:

• getElementById takes no # and the other two take no .: they receive names, not selectors. Getting this wrong is a classic mistake that returns null with no explanation.
• The two getElements… return live collections, with everything that implies (lesson 06-01, section 6): if you add an <li> with the class, it shows up in the collection by itself; if you loop with a classic for while adding elements, you get an infinite loop.
• If there are no matches, getElementById returns null and the other two return an empty collection, not null. They are two different ways of saying "nothing", and confusing them causes different errors.

getElementById is still perfectly valid and is the fastest of them all, because the browser keeps an internal index of ids. The other two have been practically displaced by querySelectorAll.

These two methods accept any CSS selector and are the ones you will use 90 % of the time.

Four things worth internalizing:

They return null or an empty list, and you have to account for it. This is the most frequent TypeError in the whole module:

The correct guard uses what you already know from 01-06 and from Module 2:

querySelectorAll returns a static NodeList. It is a snapshot of the moment: if you add tasks to the DOM afterwards, that list does not grow. In practice that is an advantage, because it removes the surprises of live collections.

The NodeList does have forEach, even though it still has no map or filter:

The selector must be valid, or the method throws an exception instead of returning null:

Watch out for one specific case: ids that start with a number are valid in HTML but break the selector (#1 is not a legal selector). If you generate ids from data, prefix them with a letter (task-1) or use [data-id="1"], which does not have that problem. And for general cases there is CSS.escape(value).

About performance: getElementById is faster than querySelector('#id') because it does not have to parse the selector. The difference is a matter of nanoseconds and does not matter except inside a loop that runs thousands of times. The sensible rule is to use querySelector/querySelectorAll for consistency, store the result in a constant and not search for the same thing twice. In 09-04 you will see how to measure this properly; until then, favor readability.

querySelector and querySelectorAll are not exclusive to document: every element has them, and then they search only among its descendants. This is fundamental for writing components that do not interfere with each other.

Comparing the two scopes makes the difference obvious:

A detail that confuses a lot of people: the selector is evaluated against the whole document, and then filtered by "must be a descendant of the element". That is why this gives unexpected results:

A selector cannot start with a combinator. If you want only the direct children starting from the element itself, use :scope:

In practice, for direct children list.children is usually enough, and you already know it and it is faster.

Two small methods with an enormous impact on the code that follows.

element.closest(selector) goes up the tree —starting with the element itself— until it finds the first ancestor that matches the selector, and returns null if it finds none. It is the robust version of chaining parentElement:

Compare with title.parentElement.parentElement.parentElement: the closest version survives any <div> somebody adds for layout reasons. Keep this method close: in 06-04 it will be the centerpiece of event delegation.

element.matches(selector) searches for nothing: it asks whether the element matches a selector, and returns a boolean.

It is the equivalent of classList.contains but with the full power of selectors, and it is ideal as the predicate of a filter:

A brief reminder from 06-01, because you will need it in every lesson: querySelectorAll returns a NodeList, not an array. It has length, brackets, forEach and is iterable, but no map, filter, reduce, sort or find.

Three properties for reading and writing the content of an element, and one difference between them that matters enormously.

The practical conclusion is twofold.

To write text, always use textContent. It is faster and, above all, safe:

innerHTML parses whatever you give it, and that is where the danger lies. If the text comes from a user —the 06-07 form, a server, the URL—, whoever writes it can inject markup and code. That is called XSS (Cross-Site Scripting):

One technical nuance that is sometimes misread: innerHTML = '<script>…</script>' does not run that <script>, but that saves nothing, because attributes like onerror, onload or onmouseover do run, and the example above is the demonstration.

The rule you should follow for the rest of the course:

textContent by default. innerHTML only with markup you wrote yourself, literal and with no external data interpolated into it. If you need to insert structure, create it with createElement (lesson 06-05) or escape the text (lesson 06-06).

There is a third reason, less serious but very real, to avoid innerHTML: reassigning it destroys and rebuilds all the inner nodes. Any event handlers you had attached to them disappear, focus is lost and any browser state (a container's scroll position, the selected text) goes with them. You will see this in detail in 06-05 and 06-06.

And about innerText: reading it forces the browser to work out what is visible, which means recalculating the page layout. It is measurable in loops. Use it only when you genuinely need "what the user sees"; for everything else, textContent.

This is one of those topics that look like a subtlety and then explain an entire bug.

• An attribute is what you write in the HTML: <input value="8" id="hours">. It lives in the markup.
• A property is a field of the DOM object: input.value. It lives in memory.

When parsing the HTML, the browser creates the property from the attribute. But from that point on they can diverge, and in fact they do.

The correct reading is: the attribute holds the initial value (what was in the HTML); the property holds the current value. To read what the user has typed, always input.value.

The attribute methods:

And the table of divergences that has to be memorized:

The case of boolean attributes deserves a warning, because it is a very common mistake:

General rule: use the properties. Fall back to getAttribute/setAttribute only for attributes that have no equivalent property —the aria-* ones, the data-* ones when you are not using dataset, or custom attributes.

HTML lets you invent attributes as long as they start with data-. They are valid, they interfere with nothing and they exist for exactly this: storing your application's data on the element that represents it.

They are read and written through the dataset property, which exposes each data-* as a key in camelCase:

The name conversion works in both directions: data-due-date ↔ dataset.dueDate. And there is a trap that costs hours if you do not know it:

Everything that comes out of the DOM is text. It is exactly the lesson of 01-07, and it will come back with forms in 06-07. Always convert explicitly, with Number().

The use we make of it here is the key piece of the whole module: data-id is the bridge between the screen and the model.

That Number(li.dataset.id) is the boundary conversion: the page speaks in strings, the model in numbers.

What to store and what not to. data-id, yes: it is a stable, minimal identifier. Duplicating the whole object on the element (data-title, data-tags, data-reviewer…) is a bad idea, because you would have two copies of the truth that can drift apart. The model is the single source of truth; the DOM stores only the key to get back to it. It is the same principle you will apply in 06-06 when reconciling the list.

classList is an object specialized in manipulating an element's class list, and its methods are exactly the ones you need:

The toggle with a second argument is especially valuable, because it turns four lines into one:

The old alternative is className, which is the whole string, and it is dangerous:

classList has none of those problems: it is idempotent, it does not duplicate and it does not destroy what you did not ask it to touch. Always use classList.

The style property gives access to the element's inline styles —the ones in the style="…" attribute—, with the CSS names in camelCase:

An important warning: style only reads what is inline, not what comes from the stylesheet.

getComputedStyle(element) returns the final styles after applying every rule. It is read-only and, as we will see in the next section, it forces the browser to compute the layout, so do not call it inside a loop.

Why classes are preferred. Changing style from JavaScript splits the presentation across two files: half in the CSS and half hidden in strings inside the JavaScript. When somebody wants to change the red of high-priority tasks, they will look in the CSS and not find it. On top of that, inline styles have extremely high specificity and are very hard to override.

The legitimate exception is values that are only known at runtime: the width of a progress bar, the position of a dragged element, a color that comes from data. Even there, the elegant approach is to use a CSS variable:

That way the how it looks keeps living in the CSS and the JavaScript only contributes the data.

Sometimes you need to know where an element is or how big it is. The DOM offers two families:

Differences worth being clear about:

And here comes the important warning. These readings are synchronous and exact: the browser is obliged to give you the correct measurement right now. If you have just modified the DOM and there are pending layout changes to compute, the browser has to stop everything and recalculate the layout (what is called a reflow or layout) before answering you. Doing it once is irrelevant; doing it inside a loop, alternating writes and reads, is catastrophic:

This pattern is called layout thrashing and has a whole lesson dedicated to it: Efficient DOM Manipulation. For now, hold on to the rule: batch reads, batch writes, and do not interleave them.

You now have all the pieces. We are going to make the three hand-written <li>s in index.html show the real data coming out of the Board: the priority class, the strikethrough if they are done, the overdue warning and the correct meta line. It is the first code in the js/view/ folder.

First we extend the HTML so each <li> has its final structure and its data-id:

And now the view module. Notice that nothing from the DOM is imported into the model: it is the view that knows about both things.

And the entry point, which stays at four lines:

On the screen you now see three tasks with their color stripe according to priority, the carpentry one marked as overdue, and the summary:

The canonical Taller Nómada numbers, for the first time outside the console. Three design decisions in this code are worth pointing out, because they set the style for the rest of the module:

• The view reads from the model, never the other way round. paintTask receives a Task and writes to the DOM. Task still does not know a page exists.
• No innerHTML. Every piece of text goes in through textContent, so a title with < or & cannot break or compromise anything.
• The class is computed, not accumulated. The remove(...Object.values(...)) before the add guarantees that calling paintTask twice with different priorities leaves the element clean. If you only did add, an <li> would end up with task--high and task--low at the same time.

What is still missing is obvious: the list still has three hand-written <li>s out of a backlog of six, and absolutely nothing happens when you click. Both are solved in the following lessons.

• getElementById('#list') with a hash. It returns null silently. getElementById takes a bare id; querySelector takes a selector with #. If you keep mixing them up, always use querySelector.
• Not checking for null. document.querySelector('#does-not-exist').textContent = 'x' throws TypeError: Cannot set properties of null. That error, when it shows up right as the page loads, almost always means the id is misspelled or the element does not exist yet.
• Using innerHTML with user data. It is the most common security hole in web applications. textContent by default, full stop. If you need structure, create it with nodes (06-05).
• setAttribute('disabled', 'false'). It leaves the element disabled, because boolean attributes act through their presence. Use the property: button.disabled = false.
• Forgetting that dataset returns strings. li.dataset.estimatedHours + 1 gives '51'. Convert with Number() at the boundary between the DOM and the model, always.
• Clobbering className. li.className = 'task--done' erases all the other classes. Use classList.add/remove/toggle.
• Repeating the same lookup inside a loop. document.querySelector('#list') inside a forEach that runs a thousand times searches a thousand times. Store the result in a constant outside the loop.
• Tip: name your selection constants deliberately. A widespread convention is to prefix DOM elements: const $list = document.querySelector('#task-list'). It is not mandatory, but it makes it clear at a glance which variables are nodes.
• Tip: closest() is your friend. Every time you catch yourself writing .parentElement.parentElement, stop and use closest('.whatever'). The resulting code is shorter and does not break when the layout changes.
• Tip: batch reads and writes. Reading offsetWidth or getBoundingClientRect() right after writing forces a layout recalculation. Measure everything first, then write everything.

Write a function inventory() that returns an object with: the total number of elements with the class task, how many have high priority, how many are overdue and the array of ids (as numbers) of the open tasks. Use querySelectorAll, conversion to an array and the methods from 04-05. Do not access the model: all the information must come from the already painted DOM.

Write highlightAssignee(name) that adds the class highlighted to the <li>s whose data-assignee matches name, and removes it from all the rest. It must work when called several times in a row with different names without leaving traces. Add to the CSS the rule needed for highlighted to be noticeable. Solve it in two ways: with classList.toggle and with matches.

Given the carpentry <li>, write a snippet that: (a) reads its data-id, (b) recovers the Task from the board, (c) marks it as in-progress using the model's method, and (d) repaints only that <li>. Check in the DOM that the class, the data-status and the aria-label have changed, and that the class task--overdue is still there. Explain why it is still there.

Exercise 1

Key points: the spread turns the NodeList into an array so you can chain filter and map; matches('.task--high') and classList.contains('task--overdue') are equivalent here, and using both shows that matches accepts full selectors while contains only takes a class name; and the Number(li.dataset.id) is essential, because without it you would get ['1', '3', '6'].

Exercise 2

Version A is the better one: a single pass, and the toggle with a second argument makes cleaning up beforehand unnecessary. Version B walks the list twice and, on top of that, interpolates a value inside a selector; if the name contained quotes or special characters, the selector could be invalid. If one day you need to build a selector from data, use CSS.escape(name).

Exercise 3

task--overdue is still there because rule R10 of the model defines "overdue" as due date in the past and task not finished. The carpentry date is 2026-09-05, earlier than TODAY = '2026-09-20', and 'in-progress' is not 'done': the task is still overdue. The class would only disappear when it moved to 'done'. Notice that the view has not had to know anything about that rule: it has simply asked task.isOverdue(today). The business rule lives in the model, the decoration in the view, and that boundary is what makes this code testable without a browser in Module 8.

You now know how to find anything on the page and change it. To select, the language is CSS selectors and the tools are querySelector (the first match, or null) and querySelectorAll (a static NodeList, possibly empty), with getElementById as the fast option for the root container and the two getElementsBy… relegated to legacy code because of their live collections. You know that both methods also exist on elements, which lets you narrow the search down to a subtree; that :scope solves the direct-children case; and that closest() goes up to the first ancestor matching a selector while matches() answers yes or no about a specific element. That closest() is by far the most important method of the lesson: it is the piece on which event delegation will be built.

To manipulate, you have the judgment rules: textContent as the default way of reading and writing text —cheap and safe—, innerText only when you genuinely need what is visible despite its recalculation cost, and innerHTML under permanent suspicion because of the XSS risk and because it destroys the inner nodes. You tell attributes (the initial value from the markup) from properties (the current value in memory), you know that for value, checked and disabled the properties rule, and that setAttribute('disabled', 'false') disables instead of enabling. You handle dataset for the data-* attributes, with the warning that everything arrives as a string and with the rule of storing only the id in the DOM and leaving the rest of the truth in the model. You use classList with its add, remove, toggle (with the second argument!), contains and replace instead of clobbering className, and you reserve style for values that only exist at runtime, preferably through CSS variables. And you know getBoundingClientRect, offsetWidth and company along with their danger: interleaving reads and writes forces layout recalculations.

In Nómada Tasks that has turned into js/view/paint.js with paintTask, paintList and paintSummary: the project's first real view layer, which takes the Tasks from the Board and dumps them into the page's <li>s with their priority classes, their strikethrough, their overdue warning and their aria-label, showing on screen the same 6 items, 45 h open and effort 124 as always.

But the page is still a poster: it can be seen, and it does not respond. If Marta clicks a task, nothing happens; if Lucía wants to see only her own, there is no way to ask for it. An application is, by definition, something that reacts to what the person using it does, and for that you need the other great pillar of the DOM: events. How a handler is registered, what information the Event object brings, why addEventListener is the only acceptable one of the three ways that exist, and why a <div> with a click leaves out anyone navigating by keyboard, is Handling Events, where Marta will finally be able to mark a task as done with a click.