In a MutationObserver callback, every MutationRecord with type 'attributes' has oldValue === null. What did the observe() call leave out, and how do you also stop unrelated attributes from generating records?

## Why oldValue is opt-in A `MutationRecord` describes a change that has already happened. For attribute and text mutations the browser could in principle keep the previous value, but doing so for every mutation on every observed node is pure overhead for the many observers that never look at it. So the DOM specification makes it a flag: `attributeOldValue: true` for attributes, `characterDataOldValue: true` for `CharacterData` nodes. Without the flag, `record.oldValue` is `null`. ```js const mo = new MutationObserver((records) => { for (const r of records) { console.log(r.attributeName, r.oldValue, r.target.getAttribute(r.attributeName)); } }); mo.observe(el, { attributes: true, attributeOldValue: true }); ``` ## The record tells you what changed, not what it became This trips people up as often as the flag does. An attribute record carries `attributeName`, `attributeNamespace` and (optionally) `oldValue` — there is no `newValue`. The current value is read from the live DOM through `record.target`. That has a consequence worth saying out loud in an interview: because delivery is asynchronous and batched, by the time you read `target.getAttribute(...)` you get the value *now*, which may be several mutations later than the record you are looking at. If you need an exact history, reconstruct it from the sequence of `oldValue`s rather than from repeated live reads. ## attributeFilter narrows what is recorded `attributeFilter` takes an array of local attribute names: ```js mo.observe(el, { attributes: true, attributeFilter: ['data-state', 'aria-expanded'] }); ``` Any other attribute write on that element produces no record at all — the filtering happens before allocation, so this is cheaper than receiving everything and skipping records in your callback. On a busy page where framework code rewrites `class` or `style` constantly, a filter is often the difference between a quiet observer and one that runs on every frame. ## The two convenience implications Passing `attributeOldValue` or `attributeFilter` without mentioning `attributes` implies `attributes: true`, so `observe(el, { attributeFilter: ['class'] })` is a valid registration. The same applies to `characterDataOldValue`, which implies `characterData: true`. But contradicting yourself is an error: `{ attributes: false, attributeOldValue: true }` throws a `TypeError` rather than being quietly ignored. ## characterData is the symmetric case For text mutations the flag is `characterDataOldValue: true`, and the record's `target` is the `Text` (or `Comment`) node itself; `oldValue` is the string it held before, and the current string is `target.data`. Remember that observing an element for text edits also needs `subtree: true`, because the mutation belongs to the child text node. ## childList records never have an oldValue `oldValue` is `null` on every `childList` record, and there is no flag that changes that. What was there before is expressed structurally instead: `removedNodes` holds the nodes that left, `addedNodes` the nodes that arrived, and `previousSibling`/`nextSibling` locate where the change happened in the child list. Those `removedNodes` entries are live references to detached nodes, which is why holding a large array of records for a long time also holds a chunk of detached DOM in memory. ## What a good answer sounds like "`oldValue` is null because the registration did not ask for it — add `attributeOldValue: true`. The record only names the attribute; I read the new value from `record.target`. And if I only care about a couple of attributes I pass `attributeFilter` so the rest never allocate records." That covers the flag, the missing `newValue`, and the cost control in three sentences.