Shadow DOM ist eine Technik der Webentwicklung, mit der sich einem HTML-Element ein eigener, gekapselter DOM-Teilbaum außerhalb des regulären Dokumentbaums zuordnen lässt. Diese Kapselung schränkt die Wirkung von CSS-Regeln und den Zugriff über DOM-APIs zwischen dem Teilbaum und dem umgebenden Dokument ein. Shadow DOM ist im DOM-Standard der WHATWG beschrieben.^[1][2]

Gemeinsam mit Custom Elements und HTML-Templates bildet Shadow DOM eine der grundlegenden Techniken der Web Components, mit denen sich wiederverwendbare Komponenten als eigene HTML-Elemente bereitstellen lassen. Die Kapselung ermöglicht es, den internen Aufbau einer Komponente gegenüber der einbettenden Seite weitgehend zu verbergen und Namenskonflikte zwischen den CSS-Regeln der Komponente und ihrer Umgebung zu vermeiden.^[3][4]

Das Konzept des Shadow DOM entstand ab 2011 im Umfeld der Google-Entwickler Dimitri Glazkov und Alex Russell, die es als Bestandteil eines Komponentenmodells für das Web vorschlugen. Das W3C veröffentlichte ab 2012 Arbeitsentwürfe für eine eigenständige Shadow-DOM-Spezifikation.^[5][6]

Eine erste, später als Shadow DOM v0 bezeichnete Variante wurde 2014 in Google Chrome eingeführt. Andere Browserhersteller beteiligten sich zunächst nicht an ihrer Umsetzung. Zur Verbreitung trug insbesondere die JavaScript-Bibliothek Polymer bei, die fehlende Browserfunktionen mit Polyfills und dem simulierten Shady DOM bereitstellte.^[7][8]

Nach einer Überarbeitung der Spezifikation entstand Shadow DOM v1, das anschließend von mehreren Browserherstellern implementiert wurde. Google Chrome unterstützte die neue Fassung ab Version 53 (2016), Safari ab Version 10 (2016), Firefox ab Version 63 (2018) und Microsoft Edge ab Version 79 (2020), nachdem der Browser auf Chromium umgestellt worden war. Die Unterstützung für Shadow DOM v0 wurde mit Chrome 80 im Jahr 2020 entfernt.^[9][10]

Die eigenständige W3C-Spezifikation wurde 2018 als Working Group Note veröffentlicht und anschließend nicht weiterentwickelt. Ihre Inhalte gingen stattdessen in den DOM Standard, den HTML Standard der WHATWG sowie das CSS-Modul CSS Scoping ein, in denen Shadow DOM seither standardisiert wird.^[6]

Das Element, an dem ein solcher Teilbaum hängt, heißt Shadow Host. Dessen Wurzelknoten wird als Shadow Root und der darin enthaltene Teilbaum als Shadow Tree bezeichnet. Die Grenze zwischen dem Shadow Tree und dem übrigen Dokument wird als Shadow Boundary bezeichnet. Erzeugt wird ein Shadow Tree durch den Aufruf der Methode attachShadow() auf dem Host. Dies ist nur für bestimmte HTML-Elemente zulässig, darunter autonome Custom Elements und einige eingebaute HTML-Elemente. Der Parameter mode bestimmt, ob der Baum von außen über die Eigenschaft shadowRoot erreichbar ist. Der geschlossene Modus dient dabei nicht als Sicherheitsmechanismus, sondern verhindert lediglich den direkten Zugriff über diese öffentliche Eigenschaft.^[2][11]

Ursprünglich ließ sich ein Shadow Tree ausschließlich per Skript erzeugen, wodurch die direkte Auslieferung vollständig gekapselter Komponenten im HTML-Markup erschwert wurde. Der deklarative Shadow DOM ermöglicht dagegen die Definition von Shadow Trees direkt im HTML-Markup. Dabei wird ein <template>-Element mit dem Attribut shadowrootmode beim Parsen des Dokuments automatisch zur Erzeugung eines Shadow Root für das übergeordnete Element verarbeitet. Die standardisierte Variante wird von den gängigen Browser-Engines unterstützt.^[12][13]

Damit eine Komponente Inhalte des umgebenden Dokuments aufnehmen kann, markiert das Element <slot> im Shadow Tree die Stellen, an denen Kindknoten des Hosts eingeblendet werden. Ereignisse überschreiten die Grenze nur, wenn sie als composed gekennzeichnet sind. Der Browser passt dabei die Zielangabe des Ereignisses durch sogenanntes Event-Retargeting an, sodass außerhalb der Komponente in der Regel nur der Shadow Host sichtbar ist.^[1]

CSS-Regeln gelten grundsätzlich nur innerhalb des Baums, in dem sie definiert wurden. Ein <style>-Element im Shadow Tree beeinflusst das übrige Dokument nicht, und allgemein gehaltene CSS-Selektoren des Dokuments greifen umgekehrt nicht in die Komponente hinein. Ausnahmen bilden unter anderem vererbte Eigenschaften. Ebenso berücksichtigen Suchmethoden wie document.querySelector() Shadow Trees nicht, weshalb Skripte außerhalb des Shadow Trees die inneren Elemente einer Komponente nicht über gewöhnliche DOM-Abfragen erreichen.^[3][2]

Für gezielte Ausnahmen stellt CSS eigene Selektoren bereit, darunter die Pseudoklasse :host für das Wirtselement sowie die Pseudoelemente ::slotted() für eingeblendete Fremdinhalte und ::part() für ausdrücklich freigegebene Bestandteile. Da benutzerdefinierte CSS-Eigenschaften die Grenze durchdringen und vererbt werden, dienen sie als übliches Mittel, um Komponenten an ein Corporate Design anzupassen.^[2][14]

Browser verwenden Shadow DOM auch intern zur Implementierung eingebauter Bedienelemente. Der innere Aufbau eingebauter Komponenten liegt in Shadow Trees, etwa Teile der Standardsteuerung eines <video>-Elements, die sich nur in den Entwicklerwerkzeugen sichtbar machen lassen.^[2]

Shadow DOM wird von allen gängigen Webbrowsern unterstützt. Die Spezifikation wurde schrittweise in die Browser-Engines integriert. Unterstützung besteht unter anderem in Chromium-basierten Browsern, Mozilla Firefox und Safari. Nicht unterstützt wird Shadow DOM vom eingestellten Internet Explorer.^[9] Typische Einsatzbereiche sind herstellerunabhängige Komponentenbibliotheken, Design-Systeme und Architekturen mit Microfrontends.^[14]

Kritik richtet sich unter anderem auf die Auswirkungen der Kapselung auf die Barrierefreiheit und die Wartbarkeit von Komponenten. Referenzen zwischen Elementen, beispielsweise über ARIA-Attribute wie aria-labelledby, können durch Shadow-Grenzen eingeschränkt sein, wenn sich die beteiligten Elemente in unterschiedlichen DOM-Bäumen befinden oder eine Shadow Boundary überschritten werden müsste. In der Praxis müssen Komponentenentwickler daher geeignete Schnittstellen vorsehen oder bestimmte Inhalte außerhalb der Kapselung platzieren.^[15][16]

Die Abgrenzung von Shadow Trees erschwert außerdem manche Formen automatisierter Tests und die nachträgliche Anpassung fremder Komponenten. Bibliotheken auf Basis von Shadow DOM müssen deshalb häufig eigene Anpassungspunkte und Programmierschnittstellen bereitstellen, damit Anwender Komponenten erweitern oder anpassen können.^[14]

• Shadow DOM verwenden – Einführung und Referenz in der Dokumentation des Mozilla Developer Networks