Shadow DOM
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.<ref name="whatwg-dom">DOM Standard – Shadow trees. In: dom.spec.whatwg.org. WHATWG, abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref><ref name="mdn">Shadow DOM verwenden. In: developer.mozilla.org. Mozilla Foundation, abgerufen am 25. Juli 2026.</ref>
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.<ref name="t3n">Kathrin Stoll: Web Components: So verwendest du Code plattformübergreifend wieder. In: t3n.de. yeebase media GmbH, 6. Mai 2020, abgerufen am 25. Juli 2026.</ref><ref>Christian Liebel: Single-Page Applications ohne Framework: Web Components als Ersatz für React & Co.? In: heise.de. Heise Medien GmbH & Co. KG, 23. Juli 2020, abgerufen am 25. Juli 2026.</ref>
Geschichte[Bearbeiten]
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.<ref name="devopedia">Web Components. In: devopedia.org. Devopedia, abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref><ref name="w3c-note">Dimitri Glazkov, Hayato Ito: Shadow DOM. W3C Working Group Note. In: w3.org. W3C, 1. März 2018, abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref>
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.<ref>Wilson Page: The State of Web Components. In: hacks.mozilla.org. Mozilla Foundation, 9. Juni 2015, abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref><ref>Stefan Neumann: Zukunft der Webentwicklung: Webkomponenten und Progressive Web Apps, Teil 1. In: heise.de. Heise Medien GmbH & Co. KG, 21. Oktober 2016, abgerufen am 25. Juli 2026.</ref>
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.<ref name="caniuse">Alexis Deveria: Shadow DOM (V1). In: caniuse.com. Abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref><ref>Deprecations and removals in Chrome 80. In: Chrome for Developers. Google LLC, 19. Dezember 2019, abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref>
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.<ref name="w3c-note" />
Funktionsweise[Bearbeiten]
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.<ref name="mdn" /><ref>Element: attachShadow()-Methode. In: developer.mozilla.org. Mozilla Foundation, abgerufen am 25. Juli 2026.</ref>
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.<ref>Declarative Shadow DOM. In: webkit.org. Apple Inc., 13. Februar 2023, abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref><ref>ShadowRoot: mode-Eigenschaft. In: developer.mozilla.org. Mozilla Foundation, abgerufen am 25. Juli 2026.</ref>
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.<ref name="whatwg-dom" />
Kapselung[Bearbeiten]
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.<ref name="t3n" /><ref name="mdn" />
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.<ref name="mdn" /><ref name="liebel2022">Christian Liebel: Micro-Frontends mit Web Components. In: heise.de. Heise Medien GmbH & Co. KG, 18. Januar 2022, abgerufen am 25. Juli 2026.</ref>
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.<ref name="mdn" />
Verbreitung und Kritik[Bearbeiten]
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.<ref name="caniuse" /> Typische Einsatzbereiche sind herstellerunabhängige Komponentenbibliotheken, Design-Systeme und Architekturen mit Microfrontends.<ref name="liebel2022" />
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.<ref>Accessible Names and Descriptions - WAI-ARIA Authoring Practices Guide. In: w3.org. World Wide Web Consortium, abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref><ref>Nolan Lawson: Shadow DOM and accessibility: the trouble with ARIA. In: nolanlawson.com. 28. November 2022, abgerufen am 25. Juli 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref>
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.<ref name="liebel2022" />
Weblinks[Bearbeiten]
- Shadow DOM verwenden – Einführung und Referenz in der Dokumentation des Mozilla Developer Networks
Einzelnachweise[Bearbeiten]
<references responsive />