No public API yet — crate isn't usable as a published dependency

[casoon]

Problem

Everything in this crate is pub(crate): parse(), Document, NodeId, NodeKind, Attribute, Position. This is deliberate per the project's Step 1 scope (see CLAUDE.md/README's "Scope" section) — building only what html-conform needs, no premature public API — but as a consequence, the crate can't be depended on by anything outside itself yet, including html-conform, even though that's the entire reason the project exists.

Solution path

This is Step 2 of the plan already described in README.md/CLAUDE.md, but it doesn't have to be "the big generic extraction" all at once — split it:

1. Minimal pub surface for html-conform integration (near-term, unblocks the actual reason this crate exists):
   • pub fn parse(input: &str) -> Document in lib.rs.
   • pub the Document/NodeId/NodeKind/Attribute/Position types and their accessor methods (Document::root, Document::children, Document::node, Document::parent, ...) — just what an html-conform::infoset::normalize()-equivalent needs to walk the tree, nothing from Tokenizer/TreeBuilder internals.
   • Add rustdoc comments to the newly-public surface (current doc comments were written for an internal audience; review them with an external reader in mind).
   • Keep Tokenizer/TreeBuilder and everything else pub(crate) — no reason to commit to their shape publicly yet.
2. Validate against html-conform's real usage: once html-conform can actually depend on this crate (path or git dependency first, not necessarily published to crates.io yet), write the adapter layer in html-conform's own repo (its src/infoset.rs-equivalent) that replaces its current HTML5-parsing dependency, and run html-conform's existing test suite against it. This is explicitly cross-repo work — not something this repo's issue tracker should try to own end to end — but this issue can track whether the pub surface from step 1 turns out to be sufficient, and adjust based on what that integration actually needs.
3. Full generic extraction (the actual "Step 2"): only after step 2 above is proven, revisit whether to extract a fully generic, html-conform-agnostic WHATWG tokenizer/tree-builder as this crate's real public API (per the two-stage plan) — e.g. exposing Tokenizer/TreeBuilder themselves, supporting fragment parsing, etc. Track as a separate, later issue once there's real signal for what "generic" needs to mean in practice, not speculatively.
4. Once there's a real pub surface, publish to crates.io (currently explicitly not published, per README).

Recommend tackling step 1 first — it's small, mechanical, and is the actual blocker for html-conform integration.

[casoon]

Step 1 done in 1cf3b31: pub fn parse, Document, NodeId, NodeKind, Node, Attribute, Position, Children are now public (read-only: Document::root/node/parent/children). Tokenizer/TreeBuilder and all mutation (new_node/append_child/insert_before/remove/...) stay crate-internal.

build/test (213 passing)/fmt --check/clippy -D warnings/cargo doc all green.

Steps 2 (validate against html-conform's real usage) and 3 (full generic Tokenizer/TreeBuilder extraction) are still open — left as deliberate follow-up decisions per plan/00-STATUS.md, not taken up automatically. Keeping this issue open to track those.

[casoon]

Progress toward a first crates.io publish: the project owner asked to close out the three documented "Known limitations" first (frameset, real `` content, ``), independent of whether html-conform itself needs them — tracked in `plan/DECISIONS.md`/`plan/04-frameset.md`.

Frameset insertion modes (§13.2.6.4.18-21) done in 507667a — "in frameset"/"after frameset"/"after after frameset" implemented, `` correctly wired into "in body"/"after head" (was a no-op stub before). Found and fixed two unrelated bugs along the way (missing frameset-ok flag update, a test whose premise only held because of that bug).

1,610/1,726 conformance cases now pass (93%, up from 90%).

Next: real `` content model, then ``, then the actual publish.

[casoon]

Second of the three pre-publish gaps done in 4cbd26d: ``'s classic content model — real `NodeKind::DocumentFragment` "template contents" (modeled as the template element's sole tree child), the stack of template insertion modes, "in template" mode (§13.2.6.4.16), the active-formatting-elements marker, and the content-fragment redirect in `appropriate_place_for_inserting_a_node`.

Deliberately not implemented: declarative shadow DOM (`shadowrootmode`) and content patching (`for` attribute) — much newer, more involved sub-features layered onto `` in the current spec text. Checked, not assumed: no vendored html5lib-tests `.dat` file exercises either (`grep -l shadowroot`/`grep '<template for'` both empty across the whole corpus). Documented as scope boundaries in README and `plan/05-template.md`.

1,722/1,726 conformance cases now pass (99.8%, up from 93%) — all 112 previously template-only known-failures fixed. Only 4 known-failures remain, all ``.

Last of the three gaps left: `` (the customizable `` proposal). Then the actual `cargo publish`.

[casoon]

Third and last of the three pre-publish gaps done in 2ecb17f: ``.

Worth noting: unlike frameset/template, this one isn't a tree-construction (§13.2.6) feature at all — `grep selectedcontent` over the full raw parsing.html spec text comes back empty. It's ``'s own HTML-parser-specific hook, defined in form-elements.html §4.10.10/.17 ("maybe clone an option into selectedcontent", run "when an option element is popped off the stack of open elements"). Flagged that scope-nature finding before proceeding; got the go-ahead to implement it anyway.

Selectedness is computed lazily from current tree state at each pop-check (last `selected`-marked option wins, else the first) instead of as incrementally-maintained per-option state — this crate never scripts or mutates the tree post-parse, so that's provably equivalent, verified by hand against the corpus's two non-trivial cases before writing any code. Added `Document::clone_subtree` (the one new generic primitive needed) and implemented `TreeBuilder::stop_parsing` (§13.2.7) for real for the first time (previously a documented no-op) — needed because its final "pop everything" step is what triggers the hook for a `` still open at EOF. Result: 1,726/1,726 conformance cases pass (100%). All three README "Known limitations" are now closed. Next: the actual `cargo publish` — the reason this whole line of work started.

[casoon]

Erledigt für die Schritte 1, 2 und 4.

• lib.rs exportiert parse, ParseResult, Document, Node, NodeId, NodeKind, Attribute, Children, Position, ParseError und ParseErrorKind öffentlich; Tokenizer und TreeBuilder bleiben pub(crate), wie hier vorgeschlagen.
• html-conform hängt seit 0.2.x an html5-parser (heute =0.4.0, aus der Registry) und benutzt es in parse.rs, infoset.rs und table_integrity.rs. Die Integration aus Schritt 2 ist also gelaufen, und die pub-Fläche hat dafür gereicht.
• Veröffentlicht: crates.io 0.4.0. Der Stand ist jetzt auch als v0.4.0 getaggt.

Offen bleibt nur Schritt 3, die generische Extraktion (Tokenizer/TreeBuilder öffentlich, Fragment-Parsing). Dafür gibt es weiterhin kein Signal aus echter Nutzung; das gehört in ein eigenes Issue, wenn es so weit ist. Deshalb hier zu.