In the browser DOM, when do node.parentNode and node.parentElement return different things, and which should a loop that climbs toward the root use?

## The definition Both properties are read-only accessors for "what contains me", and they differ only in the type filter: - `node.parentNode` — the containing node, whatever kind it is: an `Element`, a `Document`, or a `DocumentFragment`. - `node.parentElement` — the same node **if** it is an `Element`; otherwise `null`. Because almost every node in an ordinary page is contained by an element, the two are equal almost everywhere, which is why the distinction only bites at the boundaries. ## The three places they diverge **1. The document element.** `<html>` is the root element, but it is not the root *node* — the `Document` (`nodeType` 9) sits above it. ```js document.documentElement.parentNode === document; // true document.documentElement.parentElement; // null ``` This is the divergence that shows up in real code, because it is where an upward walk ends. **2. Inside a DocumentFragment.** A `DocumentFragment` (`nodeType` 11) is a parentless container that holds children but is not an element and is never rendered. A node you have placed in a fragment has a `parentNode` — the fragment — and a `null` `parentElement`. A shadow root is a `DocumentFragment` too, so a node at the top of a shadow tree behaves the same way. **3. A detached node.** A node created with `document.createElement` and not yet inserted anywhere has `null` from both properties. This is the case people forget when they assume `parentNode` is always truthy for "a real element". ## Why the climbing loop matters The classic hand-rolled ancestor search: ```js function findAncestorWithClass(node, cls) { let current = node.parentElement; while (current) { if (current.classList.contains(cls)) return current; current = current.parentElement; } return null; } ``` With `parentElement`, the loop is safe by construction: every value it ever holds is an `Element`, so `classList` exists, and the walk terminates at `<html>` because `documentElement.parentElement` is `null`. Swap in `parentNode` and two things change. The loop takes one extra step onto the `Document` node, which has no `classList` — so the very next `current.classList.contains(...)` throws a `TypeError`. And if the subtree you started in is detached inside a fragment, the loop stops at the fragment, which also has no `classList`. Both failures happen only in edge cases, which is exactly what makes them the bug that reaches production. The DOM already provides `closest()` for the selector-matching version of this walk, so hand-rolled climbing should be rare — but when you need a predicate a selector cannot express, `parentElement` is the property to climb with. ## Which one to reach for - **Reading or acting on an ancestor's element API** (classes, attributes, geometry, styles): `parentElement`. The `null` is the useful answer, because there is nothing element-shaped up there. - **Structural work that must handle any container**: `parentNode`. Removal code, node-moving helpers and generic serializers care that a node has *a* parent, not that the parent is an element. `node.parentNode.removeChild(node)` is the historical idiom for exactly this reason — though `node.remove()` supersedes it and needs no parent reference at all. - **"Is this node in the live document?"** — neither property answers that on its own; a chain of parents ending at a fragment still looks attached locally. `document.contains(node)` or `node.isConnected` answers it directly. ## A note on browser support `parentElement` is universally supported on nodes in every browser in use today; the only historical wrinkle is that in very old versions it existed on elements before it existed on all node types. There is no compatibility reason to prefer `parentNode` in new code. ## What the interviewer is looking for The weak answer is "they are the same thing". The strong answer names at least the `documentElement` case, explains that the difference is a type filter rather than a different traversal, and connects it to a concrete consequence: a climbing loop written with `parentNode` can hand you a `Document` and then fail on an element-only call.