Current status
Compact parsing now constructs directly through AngleSharp's handle-oriented tree builder into an arena backed by integer handles and pooled columns. It does not build an intermediate mutable or read-only wrapper tree.
Already present on main:
- public string, character-memory, byte-memory, and bounded async stream inputs;
- FrozenColumns and Packed publication paths;
- focused differential coverage for foster parenting, formatting adoption, templates, SVG/MathML integration points, malformed markup, text ownership, and both layouts;
- a maintained
CompactBuildStageBenchmark for arena setup, combined construction, and publication;
- documented retained-layout and performance decisions in
docs/COMPACT_DOM_DECISION.md.
The remaining gap is a precise full-fidelity contract and broader tree-construction parity, not another public parser-profile hierarchy.
Remaining work
1. Document the fidelity contract
- State exactly what the default Compact parser retains and suppresses. Today the default suppresses comments and processing instructions.
- Document how caller-provided
HtmlParserOptions opt back into additional node kinds and which browser-only behaviors are intentionally unsupported.
- Keep extraction-oriented suppression as explicit parser/plan policy rather than a second construction architecture.
2. Adopt a tree-construction corpus
- Differentially compare canonical Compact and standard AngleSharp trees over the relevant html5lib tree-construction corpus.
- Cover comments, doctypes, whitespace-sensitive text, duplicate attributes, malformed EOF, templates, foster parenting, adoption agency, implied elements, and foreign content.
- Run the corpus across both FrozenColumns and Packed output where applicable.
3. Complete performance decomposition
The current stage benchmark separates arena setup, combined construction, and publication. Extend measurement only where it changes a decision:
- byte-to-UTF-16 decoding;
- tokenizer/tree-builder work versus arena mutation;
- publication and retained-text ownership;
- name/attribute classification and wrapper/reference counts that remain after the handle seam.
Use canonical-tree parity as the gate for every optimization.
Acceptance criteria
Non-goals
- Mutable DOM compatibility, scripting, layout, browser events, or style processing.
- Raw UTF-8 storage as a prerequisite for the retained full-fidelity lane.
- Post-parse mutation/rewrite APIs.
- Public storage handles, arena columns, or diagnostic machinery.
Current status
Compact parsing now constructs directly through AngleSharp's handle-oriented tree builder into an arena backed by integer handles and pooled columns. It does not build an intermediate mutable or read-only wrapper tree.
Already present on
main:CompactBuildStageBenchmarkfor arena setup, combined construction, and publication;docs/COMPACT_DOM_DECISION.md.The remaining gap is a precise full-fidelity contract and broader tree-construction parity, not another public parser-profile hierarchy.
Remaining work
1. Document the fidelity contract
HtmlParserOptionsopt back into additional node kinds and which browser-only behaviors are intentionally unsupported.2. Adopt a tree-construction corpus
3. Complete performance decomposition
The current stage benchmark separates arena setup, combined construction, and publication. Extend measurement only where it changes a decision:
Use canonical-tree parity as the gate for every optimization.
Acceptance criteria
Non-goals