pub enum NodeKind {
Document,
Element {
name: String,
namespace: Option<String>,
attributes: Vec<Attribute>,
},
Text {
content: String,
},
Comment {
content: String,
},
ProcessingInstruction {
target: String,
data: String,
},
Doctype {
name: Option<String>,
public_identifier: Option<String>,
system_identifier: Option<String>,
},
DocumentFragment,
}Expand description
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).
Variants§
Document
The document node — there is exactly one per Document.
Element
An element node, e.g. <div class="x">.
Text
A text node.
Comment
A comment node.
ProcessingInstruction
A processing instruction node, e.g. <?target data?>. Every
insertion mode’s token dispatch has an explicit “processing
instruction token” branch (verified against the raw spec text,
not assumed) that inserts one of these — html-conform’s
normalize() drops it afterwards, but tree-construction still
puts it in the tree, so the node kind exists here too.
Doctype
A DOCUMENT TYPE node, e.g. <!DOCTYPE html>. Also dropped by
html-conform::normalize(), but inserted into the tree by the
“initial” insertion mode per spec, same reasoning as above.
DocumentFragment
A template element’s “template contents” — an inert fragment
root that real content inserted “inside” a template element
actually lands in, per §13.2.6.1’s “appropriate place for
inserting a node”. Modeled here as the template element’s sole
real tree child (created alongside it, see
tree_builder.rs::create_element_for_token), since Document
has no separate out-of-tree fragment concept — matching how
html5lib-tests’ own #document dump format represents it (a
synthetic content line, with the real children nested one
level below that).