An HTML attribute, resolved to its (possibly foreign-content-adjusted)
namespace during tree construction — see plan/03-tree-construction.md’s
Foreign-Content-Dispatch step.
A single node in a Document’s arena: its kind/payload, its source
position (None for the document node itself and for any node a
tree-construction algorithm synthesizes rather than parses — e.g. an
implied <html>/<head>/<body> — Some for everything else), and
its tree-navigation links.
A single WHATWG “parse error” (§13.2.2) — a point where the input
deviated from strict grammar but the tokenizer still recovered per its
own well-defined algorithm. Never fatal: crate::Document
construction always completes regardless of how many of these occur.
parse’s return value: the parsed Document tree plus every
WHATWG “parse error” (§13.2.2) encountered along the way. Both fields
together, not a Result — parse errors are never fatal, document
is always complete regardless of how many occurred (see
ParseError’s doc comment).
A source position: where a node parsed from the input started.
Matches html-conform::finding::SourceLocation’s field layout exactly
so the eventual integration (Phase 05) needs no conversion.
The kind of a document node and its associated data. Mostly covers
what the HTML5 tokenizer can actually produce a token for (§13.2.5’s
token kinds) — no CData/EntityRef variants, since the HTML5
tokenizer never emits those (character references and CDATA content
both resolve straight to character tokens, see
tokenizer::TokenKind’s doc comment). DocumentFragment
is the one exception: not tokenizer-token-shaped at all, synthesized
directly by tree construction (§13.2.6.1’s “create an element for a
token” step, for template elements specifically).
Which WHATWG “parse error” (§13.2.2) occurred. Variant names mirror
the spec’s own kebab-case error identifiers, translated to
PascalCase. Only variants this crate actually detects and reports
exist — no catch-all/string-payload variant, so matching on a
specific kind stays meaningful. #[non_exhaustive] because more
variants may still be added: the tokenizer level (§13.2.5,
plan/07-parse-errors.md) is complete at 50 of the 52 named errors,
but the tree-construction level (§13.2.6,
plan/08-tree-construction-errors.md) covers only the conditions
with a demonstrated consumer need, not all of §13.2.6’s unnamed
ones — adding one later must not be a breaking change for any caller
matching on this type.
The driver loop (§13.2 “Parsing HTML documents”, the “tokenization and
tree construction” step): parses input into a Document tree with
per-node source positions, feeding it through the tokenizer and handing
each token to the tree builder, applying the two pieces of feedback
tree construction sends back to the tokenizer — a state switch
(Tokenizer::switch_to, for RCDATA/RAWTEXT/script-data/PLAINTEXT
elements) and the foreign-content flag (Tokenizer::set_in_foreign_content,
consulted only by CDATA-section handling).