Sie schreiben eine HTML-Datei. Ein paar Zeilen Text, ein paar spitze Klammern. Dann drücken Sie auf „Aktualisieren“.

Und sehen etwas, das nicht mehr Ihre Datei ist.

Der Browser hat Ihren Text genommen und daraus ein begehbares Gebäude gemacht. Eines, durch das man laufen kann. In dem man Wände versetzt, Räume hinzufügt, Möbel austauscht, während die Besucher schon drin sind. Dieses stehende Gebäude, nicht der Bauplan, ist das DOM.

Wer Webseiten baut, baut nie wirklich HTML. Er baut das DOM.

Das DOM bildet HTML als lebendige Baumstruktur ab, in der Elemente, Knoten und Textinhalte per Skript verändert werden können.

Was das DOM wirklich ist

Das Document Object Model ist die plattform- und sprachenneutrale Schnittstelle, über die ein Programm auf Struktur und Inhalt eines HTML-, SVG- oder XML-Dokuments zugreift und beides zur Laufzeit verändert. Im Browser ist dieses Programm meistens JavaScript.

Die Sprache, in der das DOM denkt, ist der Baum. Oben die Wurzel, das Document. Darunter verzweigen sich Knoten (Nodes): Elemente, Texte, Kommentare. Jedes Tag, das Sie schreiben, wird ein Ast. Jeder Satz dazwischen ein Blatt.

Das ist der entscheidende Gedanke. HTML ist statischer Text. Das DOM ist die lebendige Übersetzung davon, mit der Skripte sprechen können. Die Brücke zwischen dem, was Sie geschrieben haben, und dem, was passiert, während jemand klickt.

Gepflegt wird dieses Modell heute von der WHATWG als sogenannter Living Standard.

Vom Standard-Wirrwarr zum lebenden Dokument

Das DOM ist nicht über Nacht entstanden. Es wuchs in Stufen.

DOM Level 1 legte 1998 das Fundament: Kernobjekte, das Knotenmodell, die ersten Manipulationen. DOM Level 2 brachte 2000 die Events, Namespaces und Module für CSS und HTML dazu. DOM Level 3 ergänzte 2004 weitere Kern-APIs und festigte das Ganze.

Dann der Bruch mit der Versionslogik. Heute gilt der WHATWG DOM Standard als lebendes Dokument, das sich fortlaufend verändert. Das W3C friert davon ab und zu stabile Momentaufnahmen ein.

Wer also nachschlagen will, was EventTarget normativ bedeutet, schaut nicht in die alten Level. Er schaut in den Living Standard. Das Gebäude bekommt seine Bauvorschriften nicht mehr ausgedruckt. Sie werden geschrieben, während gebaut wird.

Drei Schichten, ein Bild: DOM, CSSOM und die Render-Pipeline

Stellen Sie sich das Bauen einer Seite als Hausbau vor.

Das DOM ist der Rohbau: Wände, Räume, Treppen. Die Struktur, geparst aus Ihrem HTML.

Das CSS Object Model (CSSOM) ist der Innenausbau: Farben, Oberflächen, Maße. Es repräsentiert die geparsten Stylesheets und macht sie für Skripte lesbar und schreibbar.

Der Browser legt beide übereinander zum Render Tree, rechnet daraus das Layout (auch Reflow genannt), und malt am Ende alles aufs Pixel (Paint und Composite).

Klingt nach viel Maschinerie. Ist es auch. Und genau deshalb wird jede spätere Renovierung am DOM zur Kostenfrage. Doch dazu später.

Die Bausteine: Knoten, Elemente, Sammlungen

Vier Begriffe tragen fast alles.

Node ist die Basisklasse, von der die meisten DOM-Objekte erben. Element ist ein Tag mit Attributen, der Ort, an dem die spannenden Web-APIs hängen. Document ist der Einstieg, die Wurzel. Und DocumentFragment ist eine Art Werkbank: ein leichter Container, in dem Sie etwas zusammenbauen, bevor es ins fertige Haus kommt.

Heikel wird es bei den Sammlungen, weil zwei Sorten existieren, die sich verwirrend ähnlich anfühlen.

• Eine NodeList, etwa aus querySelectorAll, ist meist statisch. Ein Foto. Ändert sich das DOM danach, ändert sich das Foto nicht.
• Eine HTMLCollection, etwa document.forms, ist oft live. Ein Fenster mit Blick nach draußen. Ändert sich das DOM, sehen Sie die Änderung sofort.

Wer das verwechselt, iteriert durch eine Liste, die sich unter ihm verschiebt. Ein häufiger, fieser Fehler. Wollen Sie Ruhe, nehmen Sie das Foto.

Wann das Haus bezugsfertig ist

Der Parser baut den Baum nicht auf einen Schlag, sondern in Phasen. Der Zustand (document.readyState) wandert von "loading" über "interactive" zu "complete".

Zwei Ereignisse markieren die wichtigen Momente. DOMContentLoaded feuert, sobald das HTML geparst und alle defer-Skripte ausgeführt sind, ohne auf Bilder oder Frames zu warten. Das load-Ereignis kommt erst, wenn wirklich alles geladen ist.

Daran hängt eine der häufigsten Pannen überhaupt: ein Skript greift auf ein Element zu, das es noch gar nicht gibt. Wie der Maler, der streichen will, bevor die Wand steht.

Die beiden Ladeattribute beim Skript regeln das:

• defer: Laden parallel, Ausführen nach dem Parsen, in Dokumentreihenfolge, vor DOMContentLoaded. Berechenbar.
• async: Laden und Ausführen, sobald es fertig ist. Keine Reihenfolge-Garantie. Gut für Unabhängiges wie Analytics, schlecht für alles, was aufeinander aufbaut.

Im Zweifel: defer. Reihenfolge ist Ruhe.

Das DOM durchsuchen und umbauen

Sie wollen einen Raum finden? Die klassischen Wege heißen getElementById, getElementsByTagName, getElementsByClassName, wobei die letzten beiden live sind. Eleganter und meist statisch: querySelector und querySelectorAll, die mit denselben CSS-Selektoren arbeiten wie Ihr Stylesheet. Browserdetails dazu hält MDN bereit.

Für feineres Navigieren gibt es TreeWalker und NodeIterator, die nach Filterregeln durch Teilbäume wandern, sowie Range für spannengenaue Eingriffe, etwa beim Rich-Text-Editing.

Und das eigentliche Umbauen? createElement, append, before, replaceWith, cloneNode, insertAdjacentHTML. Für ganze Bautrupps auf einmal ist DocumentFragment das Mittel der Wahl, für deklarative Vorlagen das <template>-Element.

Das Ereignismodell: Capturing, Target, Bubbling

Jetzt wird das Haus lebendig. Jemand klickt.

Dieser Klick reist in drei Phasen durch den Baum. Erst von der Wurzel nach unten zum Ziel (Capturing), dann am Ziel selbst (Target), dann wieder hinauf (Bubbling). Wie ein Ruf, der durchs Treppenhaus nach unten hallt und als Echo zurückkommt.

Listener registrieren Sie mit addEventListener(type, listener, options). Die Optionen lohnen ein genaues Hinsehen, denn sie entscheiden über Performance und saubere Aufräumarbeit. capture lauscht schon beim Hinabsteigen. once entfernt den Listener nach dem ersten Mal von selbst. passive verspricht dem Browser, dass Sie kein preventDefault() rufen werden, was beim Scrollen Gold wert ist. Und signal koppelt den Listener an ein AbortSignal, sodass er sich ohne removeEventListener abschalten lässt. Das semantische Kleingedruckte steht in der Spezifikation und auf MDN.

Eigene Signale schicken Sie mit new CustomEvent('name', { detail }) und dispatchEvent. So reden Komponenten miteinander, ohne sich gegenseitig in die Innereien zu greifen.

Shadow DOM: das Zimmer mit eigenen Regeln

Manchmal wollen Sie einen Raum, in den die Hausordnung des Rests nicht hineinregiert. Eigene Wandfarbe, eigene Verkabelung, kein Durcheinander mit dem übrigen Stylesheet.

Das ist Shadow DOM. Mit Element.attachShadow({ mode: 'open' }) verankern Sie an einem Host-Element einen gekapselten Teilbaum mit eigenem Style-Geltungsbereich. <slot> lässt durch, was von außen hineingereicht wird. <template> liefert die Vorlage.

Zusammen sind das die Bausteine für Web Components, also wiederverwendbare Bausteine mit einer stabilen, öffentlichen Schnittstelle und einem privaten Innenleben. Modular statt verfilzt.

Wo es teuer wird: DOM, Performance und der Renovierungsfehler

Jetzt zur Kostenfrage von vorhin.

Jede Änderung an Geometrie oder Stil kann eine Kette auslösen: Style-Recalc, Layout, Paint, Composite. Eine Wand zu versetzen ist eben nicht nur ein Pinselstrich. Der Statiker muss neu rechnen.

Die teuerste Sünde hat sogar einen Namen: Layout Thrashing. Der ungeduldige Renovierer, der misst, bohrt, wieder misst, wieder bohrt. Wer im Wechsel aus dem DOM liest und ins DOM schreibt, zwingt den Browser, immer wieder neu zu rechnen.

Haben Sie sich je gefragt, warum eine Seite beim Scrollen ruckelt, obwohl die Hardware stark genug wäre?

Meistens liegt es hier. Die Gegenmittel sind handwerklich schlicht:

• Bündeln. Viele kleine Änderungen erst auf der Werkbank vorbereiten, im DocumentFragment, dann in einem Zug einbauen. Reduziert Reflows spürbar.
• Lesen und Schreiben trennen. Erst alle Messungen, dann alle Änderungen. Nicht im Wechsel.
• Klein bleiben. Schlanke Selektoren, überschaubare Baumgröße, bei langen Listen Techniken wie „Windowing“.

Ein gutes DOM ist kein möglichst großes. Es ist ein möglichst ruhiges.

Wo es gefährlich wird: DOM-basiertes XSS

Ein Gebäude mit unverschlossener Tür ist eine Einladung.

DOM-basiertes Cross-Site Scripting (DOM-XSS) entsteht, wenn Ihr Client-Code ungeprüfte Eingaben aus Quellen wie location, document.cookie oder postMessage direkt in gefährliche Senken schreibt, allen voran innerHTML, document.write und eval. Der Server bekommt davon nichts mit. Der Angriff läuft komplett im Browser des Besuchers.

Die Haltung dazu ist nicht verhandelbar: Ungeprüfte Daten gehören niemals in innerHTML. Punkt.

Stattdessen textContent oder setAttribute für Werte, konsequentes Escaping je nach Kontext und, wo sinnvoll, eine restriktive CSP. Besonders aufmerksam bei location.hash, searchParams und postMessage. Tiefer einsteigen können Sie bei OWASP und PortSwigger.

Wer nicht sieht, muss sich zurechtfinden: DOM und Barrierefreiheit

Aus Ihrem DOM leitet der Browser einen zweiten Baum ab: den Accessibility Tree. Das ist der Grundriss, an dem sich ein Screenreader orientiert, wenn jemand die Seite nicht sehen kann.

Hier rächt sich nachlässige Struktur sofort. Wer <div> auf <div> stapelt, baut ein Haus ohne Türschilder. Wer dagegen semantische Elemente wie <main>, <nav>, <button> und <label> nutzt, bekommt die richtigen Rollen geschenkt.

ARIA ergänzt diese Bedeutung dort, wo native Elemente nicht reichen oder wo CSS sie aushebelt, etwa wenn display: grid eine Tabellenstruktur ihrer impliziten Rollen beraubt. Aber gezielt, nicht reflexhaft. Die alte Weisheit gilt: kein ARIA ist besser als schlechtes ARIA.

Und halten Sie DOM-Reihenfolge und Fokusreihenfolge im Einklang. Ein Grundriss, in dem die Räume anders nummeriert sind als sie aufeinander folgen, hilft niemandem.

DOM gegen „Virtual DOM“

Zum Schluss ein verbreitetes Missverständnis. Frameworks wie React arbeiten mit einem virtuellen DOM, einem leichten Abbild der Oberfläche. Sie vergleichen den alten mit dem neuen Stand und wenden nur die Unterschiede aufs echte DOM an.

Das ist kein konkurrierender Standard. Es ist eine Bibliotheksstrategie, um Umbauten zu bündeln, also genau das Werkbank-Prinzip von oben, nur automatisiert. Am Ende landet jede Änderung doch auf dem realen DOM und seinen Web-Standards. Das virtuelle DOM verlegt die Arbeit. Es schafft sie nicht ab.

Was bleibt

Das DOM ist nicht die Datei, die Sie schreiben. Es ist das Gebäude, das daraus wird, und alles Interaktive, Schnelle, Sichere und Zugängliche einer Seite entscheidet sich darin.

Wer es nur als technische Pflicht behandelt, baut Wände. Wer seine Baumstruktur, seinen Lebenszyklus und seine Kosten versteht, baut Räume, in denen Menschen sich gern bewegen.

Welcher von beiden möchten Sie sein?