Web Components: Ist Shadow DOM die Rettung aus dem CSS-Wildwuchs?

Web Components: Ist Shadow DOM die Rettung aus dem CSS-Wildwuchs?

Gerade in der Arbeit an großen Web-Projekten, in denen viele Personen über einen längeren Zeitraum an der Entwicklung und der ständigen Weiterentwicklung mitwirken, können aus dem CSS handfeste Probleme entstehen. Spätestens wenn Style-Deklarationen Elemente verändern, die gar nicht angesprochen werden sollten, droht das Team zunehmend die Kontrolle über den Code zu verlieren. Auch um solche Szenarien zu vermeiden, wurden die Web Components entwickelt. Insbesondere das sogenannte Shadow DOM verspricht, CSS-Selektorenchaos gar nicht erst aufkommen zu lassen. Aber inwieweit ist diese Technologie für den Einsatz in der Breite geeignet? Wird mit Shadow DOM die Arbeit am CSS generell unkomplizierter? – Und was sind eigentlich diese Web Components?

Hintergrund: Was sind Web Components?

Hinter der Bezeichnung Web Components verbirgt sich eine Reihe von Web-Technologien, die ohne die Einbindung externer Bibliotheken (wie jQuery) oder Skripte eingesetzt werden können, da sie browserseitig unterstützt werden – allerdings nur dann, wenn der Browser diese Unterstützung auch tatsächlich mitbringt. In allen anderen Fällen hilft Google. Denn mit Polymer hat Google ein auf Web Components basierendes Framework entwickelt, das mit den sogenannten Polyfills (webcomponents.js) eingebunden werden kann, um Web Components auch in Browsern, die diese Technologien noch nicht nativ unterstützen, verfügbar zu machen. Zu den Web Components werden vier Technologien gezählt, die auch unabhängig voneinander eingesetzt werden können:

  • Custom Elements
    Eigene HTML-Elemente, die erweiterte, dynamische Gestaltungsmöglichkeiten in schlankem Web Components JavaScript erlauben.
    Mehr darüber: https://customelements.io/
  • HTML-Templates
    HTML-Elemente, die nicht unmittelbar gerendert werden, sondern im Quelltext Daten vorhalten, die zur Laufzeit per JavaScript dynamisch an den gewünschten Stellen eingesetzt werden können.
    Mehr darüber: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template
  • HTML-Imports
    Die Möglichkeit, HTML-Dateien per <link>-Tag zu importieren. Zum Beispiel so:
    <link rel="import" href="externalfile.html">
    Mehr darüber: http://w3c.github.io/webcomponents/spec/imports/
  • Shadow DOM
    Die Möglichkeit, jeweils in einem bestimmten Element im DOM ein gekapseltes Shadow DOM zu implementieren, das funktional vom umgebenden Quelltext entkoppelt ist. Damit können beispielsweise Elemente per CSS in ihrem jeweiligen Shadow DOM gestaltet werden, ohne dass dies möglicherweise ungewollte Auswirkungen auf andere Elemente hat.
    Mehr darüber unter http://webcomponents.org/articles/introduction-to-shadow-dom/ und im Folgenden.

Prominente Beispiele für vollständig mit Web Components und Googles Polymer Technologie für verbesserte Browser-Kompatibilität umgesetzte Websites sind chromestatus.com und polymer-project.org.

Wofür wurde Shadow DOM entwickelt?

Seit der Einführung von CSS und der Trennung von Inhalt und Design in der Web-Entwicklung ist die Arbeit mit HTML deutlich übersichtlicher geworden. Andererseits treibt das Hantieren mit den unterschiedlichen Selektoren gerade in großen Projekten bisweilen seltsame Blüten und kann sich zu einem schier undurchdringlichen Gestrüpp auswachsen. Denn je komplexer ein Web-Projekt, desto größer wird die Herausforderung, die Style-Eigenschaften im CSS durchweg so zu definieren, dass sie sich ausschließlich auf die gewünschten Elemente auswirken und je mehr Entwickler an einem Projekt mitarbeiten und es über einen langen Zeitraum weiterentwickeln, desto größer wird die Wahrscheinlichkeit, dass das wuchernde Chaos irgendwann unvorhersehbare Wirkungen zeitigt.

Die Entwicklung von Shadow DOM ist die Konsequenz aus diesem Horrorszenario, das schon für manchen Entwickler schreckliche Realität geworden ist: ein komplexes Projekt läuft Gefahr, im CSS-Chaos steckenzubleiben. Wenn sich eigentlich fehlerfreie Style-Deklarationen plötzlich auf Teile des Layouts auswirken, die gar nicht gemeint waren, hat ein Web-Projekt einen Punkt überschritten, an dem es teilweise unkontrollierbar wird. Die Frontend-Entwickler bewegen sich in ihrer Arbeit auf zunehmend dünnem Eis, wenn geringfügige Änderungen an anderer Stelle möglicherweise ungewollte Auswirkungen auf die Navigation haben können, oder umgekehrt. In einer solchen kritischen Situation, in der ein Neubeginn längst ausgeschlossen ist, aber auch ein “Weiter so” nicht die Devise sein kann, sollen Web Components, insbesondere Shadow DOM eine mögliche Lösung bieten. Und was noch besser ist: wenn Shadow DOM von Beginn an eingesetzt wird, dürfte man gar nicht erst an einen solch kritischen Punkt kommen. (Eine sehr gute Einführung in diese Problematik und die bestehenden Lösungsansätze liefert Philip Walton.) – Aber wie genau funktioniert Shadow DOM?

Wie genau funktioniert Shadow DOM?

Innerhalb eines HTML-Dokuments kann ein Shadow DOM implementiert werden, das einem bestehenden Element, dem sogenannten “Shadow Host” zugewiesen wird. Technisch gesehen handelt es sich also um das Anlegen eines Unterbaums im Quelltext. Innerhalb des Shadow DOM können dann Inhalte und Styles für das HTML-Element definiert werden. Der Vorteil dabei ist die doppelt wirksame Kapselung der Deklarationen im Shadow DOM. Denn zum Einen können die im Shadow DOM definierten HTML-Elemente nicht durch Style-Deklarationen von außerhalb manipuliert werden und zum Anderen gelten die im Shadow DOM enthaltenen Style-Deklarationen nur innerhalb dieses geschlossenen Bereichs, so dass sie sich also nicht auf die außerhalb liegenden Elemente auswirken. Gerendert werden Shadow DOMs schließlich jedoch gemeinsam mit dem gesamten DOM. Was sich zunächst verdächtig nach ungeheuerlichem Hexenwerk anhört, sieht im Quelltext letztlich ganz unspektakulär aus. Ein paar Zeilen JavaScript – und fertig ist das Shadow DOM:

<html>
<head></head>
<body>
<p id="hostElement"></p>

  <script>
// Das Shadow DOM für den Shadow Host erzeugen:
var shadow = document.querySelector('#hostElement').createShadowRoot();
// Ein HTML-Element im Shadow DOM anlegen:
shadow.innerHTML = '<p>Dieser Text steht im Shadow DOM.</p>';
// Das HTML-Element im Shadow DOM stylen:
shadow.innerHTML += '<style>p { color: red; }</style>';
</script>

</body>
</html>

Dieses Beispiel ist natürlich denkbar einfach gewählt und lässt den praktischen Nutzen dieser Technologie nicht auf den ersten Blick erkennen. Aber im Hinblick auf unübersichtliche Web-Projekte und angesichts der Tatsache, dass Web-Entwicklung zumeist auch nach der Livestellung sukzessiv weitergeht, so dass oftmals unzählige Änderungen und Erweiterungen hinzukommen, die zu Projektbeginn absolut nicht absehbar waren, wird die Möglichkeit, für jedes beliebige Element im DOM ein Shadow DOM einrichten zu können, um es mitsamt seinen Styleeigenschaften von seiner Umgebung abzukapseln ausgesprochen interessant. Mit Shadow DOM eröffnet sich die Möglichkeit, Styles ausschließlich für einen klar begrenzten Bereich zu definieren. So können viele Entwickler an unterschiedlichen Stellen desselben Projektes arbeiten, ohne sich dabei ins Gehege zu kommen. Und zusätzlich lassen sich die gekapselten Details für die Implementierung (Inhalte und Style-Deklarationen) von Shadow DOMs mithilfe weiterer Web Components (HTML-Templates und HTML-Imports) auslagern und verstecken, so dass der Code, auch wenn er irgendwann voller Shadow Roots und Shadow DOMs ist, immer noch gut lesbar und übersichtlich bleibt.

Die Schwachstelle: Browser-Kompatibilität

Einen Haken hat die Sache allerdings. Denn derzeit lässt die Browser-Kompatibilität von Shadow DOM – und der anderen Web Components – noch sehr zu wünschen übrig. Nativ funktionieren diese Technologien aktuell eigentlich ausschließlich in Chrome und Firefox unterstützt sie nur nach einem Eingriff in die Konfiguration (und auch dann nicht in vollem Umfang). Aber wie bereits erwähnt, hat Google schon eine Lösung für dieses Problem entwickelt. Mit den durch das Einbinden der von Google im Rahmen des Polymer Project zur Verfügung gestellten Polyfills können die meisten Features von Shadow DOM nämlich flächendeckend in allen modernen Browsern (IE ab Version 10) genutzt werden.

Hier sind die Möglichkeiten und Grenzen des Einsatzes von Shadow DOM mit Polyfills detailliert beschrieben.

Fazit

Bei den Web Components im Allgemeinen und bei Shadow DOM im Besonderen handelt es sich um enorm leistungsfähige Web-Technologien, die gerade für komplexe Projekte, die über einen langen Zeitraum ständig weiterentwickelt werden, sehr wertvolle Werkzeuge bereitstellen. Shadow DOM ist ein sicherer Weg, um der Gefahr von unkontrollierbar wucherndem CSS-Chaos zu entgehen. Die Implementierung ist übersichtlich – allerdings nur für die native Unterstützung im Browser, die bislang kaum gegeben ist. Eine gute Abdeckung lässt sich schon jetzt durch das zusätzliche Einbinden von Polyfills erreichen – allerdings wird damit auch die Implementierung von Shadow DOM ein gutes Stück komplizierter. Für den Einsatz in der Breite sind diese Web Components demnach wohl noch nicht ganz reif. Aber schon in naher Zukunft könnten sie Einzug in immer mehr Browser und damit schließlich auch in immer mehr Websites und Onlineshops halten – und dürften künftig so manchen Entwickler vor der Verzweiflung bewahren.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Newsletter abonnieren

Melden Sie sich für unseren Newsletter an und lassen Sie sich monatlich über unsere neuesten Beiträge informieren!

    Kontakt

    Genug über uns – lassen Sie uns darüber sprechen, wie wir Ihnen helfen können.