DOM Level 3 describes a historical generation of document APIs. Its tree model remains useful for understanding XML code: documents contain nodes, elements carry attributes, and text is represented separately. Maintenance work starts by separating those concepts from the particular APIs a current runtime implements.
Place the specifications in context
W3C published DOM Level 3 Core and Load and Save as recommendations on April 7, 2004. Its contemporaneous announcement describes namespace handling, text access, and document loading/saving work. Core and Load and Save are separate modules, so support for familiar tree operations does not establish support for every historical interface.
The W3C DOM specifications index points to the WHATWG DOM Standard for the living web platform. Consult historical Level 3 documents when interpreting old code, then check your actual browser or server library for the operations you intend to retain.
Understand names and nodes
A document node contains an element tree. Elements can contain text nodes, comments, and other elements; attributes are accessed through an element’s attribute interfaces. Indentation can introduce whitespace text nodes, so childNodes and element-only traversal can yield different counts.
Namespace-aware operations use a URI and local name. A prefix is a spelling convenience. To find a namespaced item, use getElementsByTagNameNS; to create one, use createElementNS. Set an ordinary unprefixed identifier with setAttribute.
Reading an element’s textContent gathers descendant text. Assigning it replaces the children with text, so use it deliberately on a leaf field. Calling normalize() merges adjacent text nodes and removes empty text nodes; it is neither schema validation nor a whitespace policy.
Run a small browser exercise
Open the DOM practice page. It uses a fixed fictional XML string and runs locally in the browser without sending input to a service. Select “Run example.” The output should report two items, the first name “Desk & Lamp,” and three items after appending a new one.
Its main operations are:
const ns = "urn:yenra:catalog";
const doc = new DOMParser().parseFromString(xml, "application/xml");
const items = doc.getElementsByTagNameNS(ns, "item");
const item = doc.createElementNS(ns, "item");
item.setAttribute("id", "C3");
doc.documentElement.appendChild(item);
const output = new XMLSerializer().serializeToString(doc);The full exercise checks parsing errors and builds a name and quantity inside the new item. It snapshots counts before changing the document because these DOM collections are live. Its malformed-input test should report rejection, not a normal document result.
Browser parsing and serialization are documented in the HTML Standard. These browser interfaces are not a promise that historical DOM Level 3 Load and Save objects exist.
Check behavior before replacing old code
| Operation | Test | What can differ |
|---|---|---|
| Parse XML | Valid and malformed input | Error reporting and document type handling. |
| Select nodes | Default and prefixed namespaces | Binding context and live collections. |
| Change text | Leaf and mixed-content elements | Loss of child markup when assigning textContent. |
| Move or copy a node | Within and between documents | Ownership, adoption, and cloning behavior. |
| Serialize | Read output back and compare meaning | Prefixes, attribute order, empty-element syntax. |
Compare parsed meaning unless byte identity is an explicit requirement. Serializers can change surface spelling without changing the tree. Signed or canonicalized documents need the relevant signature/canonicalization process; a parse-and-save round trip is not automatically safe for them.
Keep XML in a detached document during inspection. Parsing does not sanitize content for insertion into an active HTML page. The practice page displays results with textContent, avoiding markup interpretation. Server processing has its own resource-loading controls; verify those with the parser and firewall guides.