> [Shadow-DOM](https://wiki.selfhtml.org/wiki/HTML/Web_Components/Shadow_DOM)? Du meinst, es ist von Vorteil, wenn mich eine Seite mit Registrierungszwang-Overlays quälen kann, ohne dass ich über Entwicklertools an die verursachenden DOM-Elemente gelange, um diese zu entfernen? Da hast du glaube ich etwas falsch verstanden (oder ich verstehe dich falsch). Du kannst jedenfalls mit deinen Entwicklerwerkzeugen das Shadow-DOM genau so frei einsehen und verändern, wie du es mit normalen DOM-Bäumen machen kannst. Das ganze Thema hat nichts mit DRM oder ähnlichem zu tun. Die zentrale Aufgabe des Shadow-DOMs ist eher vergleichbar mit der Trennung von öffentlicher Schnittstelle und Implementierung in objektorientierten Programmiersprachen. Wenn du eine Funktions-Bibliothek in PHP oder Java schreibst, hast du für gewöhnlich öffentliche und private Funktionen. Die öffentlichen sind für den Nutzer der Bibliothek bestimmt, die privaten Funktionen für die Entwickler der Bibliothek. Private Funktionen braucht man häufig als kleine Helferlein, die aber nicht direkt mit der fachlichen Zielsetzung der Bibliothek zu tun haben, oder von denen man glaubt, dass sie sich verhältnismäßig häufig ändern werden und flexibel sein müssen. Man möchte den Nutzer davor schützen, solche internen Funktionen zu benutzen, weil er damit beim nächsten Update womöglich riesigen Aufwand hätte seine Code-Basis anzupassen. Welche Funktionen der Nutzer risikoarm benutzten kann, legt man in einer Schnittstellenbeschreibung fest. Die Implementierung dieser Schnittstelle ist dann flexibel ausgestaltbar und änderbar. Das fällt in Programmiersprachen häufig unter den Schrimbegriff der Datenkapselung. Das Shadow-DOM dient einem ähnlichen Zweck: Der Autor einer Komponente oder eines Custom-Elements möchte den späteren Anwender davor schützen, sich auf Implementierungs-Details zu stürzen, die nicht für den öffentlichen Gebrauch bestimmt sind. Das gibt dem Autor die Freiheit seine Implementierung flexibel auszugestalten und zu verändern, und schützt gleichzeitg den Anwender vor unerwarteten Effekten. JavaScript hat inzwischen auch ein Modul-System auf Sprachebene, daher kann man fragen, wieso es darüber hinaus auch noch das Shadow-DOM braucht. Der Grund ist, dass das DOM allen JavaScript-Modulen als eine globale, geteilte Ressource bereitgestellt wird, es durchtunnelt in gewisser Weise die native Datenkapselung. Das Shadow-DOM ermöglicht diese Trennung auch auf DOM-Ebene durchzusetzen. Man kommt übrigens auch weiterhin an die Implementierungs-Details heran, wenn Bedarf besteht, man muss nur das Warnschild ignorieren und unter das Flatterband hindurch schlüpfen.

> [Shadow-DOM](https://wiki.selfhtml.org/wiki/HTML/Web_Components/Shadow_DOM)? Du meinst, es ist von Vorteil, wenn mich eine Seite mit Registrierungszwang-Overlays quälen kann, ohne dass ich über Entwicklertools an die verursachenden DOM-Elemente gelange, um diese zu entfernen? Da hast du glaube ich etwas falsch verstanden (oder ich verstehe dich falsch). Du kannst jedenfalls mit deinen Entwicklerwerkzeugen das Shadow-DOM genau so frei einsehen und verändern, wie du es mit normalen DOM-Bäumen machen kannst. Das ganze Thema hat nichts mit DRM oder ähnlichem zu tun. Die zentrale Aufgabe des Shadow-DOMs ist eher vergleichbar mit der Trennung von öffentlicher Schnittstelle und Implementierung in objektorientierten Programmiersprachen. Wenn du eine Funktions-Bibliothek in PHP oder Java schreibst, hast du für gewöhnlich öffentliche und private Funktionen. Die öffentlichen sind für den Nutzer der Bibliothek bestimmt, die privaten Funktionen für die Entwickler der Bibliothek. Private Funktionen braucht man häufig als kleine Helferlein, die aber nicht direkt mit der fachlichen Zielsetzung der Bibliothek zu tun haben, oder von denen man glaubt, dass sie sich verhältnismäßig häufig ändern werden und flexibel sein müssen. Man möchte den Nutzer davor schützen, solche internen Funktionen zu benutzen, weil er damit beim nächsten Update womöglich riesigen Aufwand hätte seine Code-Basis anzupassen. Welche Funktionen der Nutzer risikoarm benutzten kann, legt man in einer Schnittstellen beschreibung fest. Die Implementierung dieser Schnittstelle ist dann flexibel ausgestaltbar und änderbar. Das fällt in Programmiersprachen häufig unter den Schrimbegriff der Datenkapselung. Das Shadow-DOM dient einem ähnlichen Zweck: Der Autor einer Komponente oder eines Custom-Elements möchte den späteren Anwender davor schützen, sich auf Implementierungs-Details zu stürzen, die nicht für den öffentlichen Gebrauch bestimmt sind. Das gibt dem Autor die Freiheit seine Implementierung flexibel auszugestalten und zu verändern, und schützt gleichzeitg den Anwender vor unerwarteten Effekten. JavaScript hat inzwischen auch ein Modul-System auf Sprachebene, daher kann man fragen, wieso es darüber hinaus auch noch das Shadow-DOM braucht. Der Grund ist, dass das DOM allen JavaScript-Modulen als eine globale, geteilte Ressource bereitgestellt wird, es durchtunnelt in gewisser Weise die native Datenkapselung. Das Shadow-DOM ermöglicht diese Trennung auch auf DOM-Ebene durchzusetzen. Man kommt übrigens auch weiterhin an die Implementierungs-Details heran, wenn Bedarf besteht, man muss nur das Warnschild ignorieren und unter das Flatterband hindurch schlüpfen.

> [Shadow-DOM](https://wiki.selfhtml.org/wiki/HTML/Web_Components/Shadow_DOM)? Du meinst, es ist von Vorteil, wenn mich eine Seite mit Registrierungszwang-Overlays quälen kann, ohne dass ich über Entwicklertools an die verursachenden DOM-Elemente gelange, um diese zu entfernen? Da hast du glaube ich etwas falsch verstanden (oder ich verstehe dich falsch). Du kannst jedenfalls mit deinen Entwicklerwerkzeugen das Shadow-DOM genau so frei einsehen und verändern, wie du es mit normalen DOM-Bäumen machen kannst. Das ganze Thema hat nichts mit DRM oder ähnlichem zu tun. Die zentrale Aufgabe des Shadow-DOMs ist eher vergleichbar mit der Trennung von öffentlicher Schnittstelle und Implementierung in objektorientierten Programmiersprachen. Wenn du eine Funktions-Bibliothek in PHP oder Java schreibst, hast du für gewöhnlich öffentliche und private Funktionen. Die öffentlichen sind für den Nutzer der Bibliothek bestimmt, die privaten Funktionen für die Entwickler der Bibliothek. Private Funktionen braucht man häufig als kleine Helferlein, die aber nicht direkt mit der fachlichen Zielsetzung der Bibliothek zu tun haben, oder von denen man glaubt, dass sie sich verhältnismäßig häufig ändern werden und flexibel sein müssen. Man möchte den Nutzer davor schützen, solche internen Funktionen zu benutzen, weil er damit beim nächsten Update womöglich riesigen Aufwand hätte seine Code-Basis anzupassen. Welche Funktionen der Nutzer risikolos benutzten kann, legt man in einer Schnittstellen beschreibung fest. Die Implementierung dieser Schnittstelle ist dann flexibel ausgestaltbar und änderbar. Das fällt in Programmiersprachen häufig unter den Schrimbegriff der Datenkapselung. Das Shadow-DOM dient einem ähnlichen Zweck: Der Autor einer Komponente oder eines Custom-Elements möchte den späteren Anwender davor schützen, sich auf Implementierungs-Details zu stürzen, die nicht für den öffentlichen Gebrauch bestimmt sind. Das gibt dem Autor die Freiheit seine Implementierung flexibel auszugestalten und zu verändern, und schützt gleichzeitg den Anwender vor unerwarteten Effekten. JavaScript hat inzwischen auch ein Modul-System auf Sprachebene, daher kann man fragen, wieso es darüber hinaus auch noch das Shadow-DOM braucht. Der Grund ist, dass das DOM allen JavaScript-Modulen als eine globale, geteilte Ressource bereitgestellt wird, es durchtunnelt in gewisser Weise die native Datenkapselung. Das Shadow-DOM ermöglicht diese Trennung auch auf DOM-Ebene durchzusetzen. Man kommt übrigens auch weiterhin an die Implementierungs-Details heran, wenn Bedarf besteht, man muss nur das Warnschild ignorieren und unter das Flatterband hindurch schlüpfen.

> [Shadow-DOM](https://wiki.selfhtml.org/wiki/HTML/Web_Components/Shadow_DOM)? Du meinst, es ist von Vorteil, wenn mich eine Seite mit Registrierungszwang-Overlays quälen kann, ohne dass ich über Entwicklertools an die verursachenden DOM-Elemente gelange, um diese zu entfernen? Da hast du glaube ich etwas falsch verstanden (oder ich verstehe dich falsch). Du kannst jedenfalls mit deinen Entwicklerwerkzeugen das Shadow-DOM genau so frei einsehen und verändern, wie du es mit normalen DOM-Bäumen machen kannst. Das ganze Thema hat nichts mit DRM oder ähnlichem zu tun. Die zentrale Aufgabe des Shadow-DOMs ist eher vergleichbar mit der Trennung von öffentlicher Schnittstelle und Implementierung in objektorientierten Programmiersprachen. Wenn du eine Funktions-Bibliothek in PHP oder Java schreibst, hast du für gewöhnlich öffentliche und private Funktionen. Die öffentlichen sind für den Nutzer der Bibliothek bestimmt, die privaten Funktionen für die Entwickler der Bibliothek. Private Funktionen braucht man häufig als kleine Helferlein, die aber nicht direkt mit der fachlichen Zielsetzung der Bibliothek zu tun haben, oder von denen man glaubt, dass sie sich verhältnismäßig häufig ändern werden und flexibel sein müssen. Man möchte den Nutzer davor schützen, solche internen Funktionen zu benutzen, weil er damit beim nächsten Update womöglich riesigen Aufwand hätte seine Code-Basis anzupassen. Welche Funktionen der Nutzer risikolos benutzten soll, legt man in einer Schnittstellen beschreibung fest. Die Implementierung dieser Schnittstelle ist dann flexibel ausgestaltbar und änderbar. Das fällt in Programmiersprachen häufig unter den Schrimbegriff der Datenkapselung. Das Shadow-DOM dient einem ähnlichen Zweck: Der Autor einer Komponente oder eines Custom-Elements möchte den späteren Anwender davor schützen, sich auf Implementierungs-Details zu stürzen, die nicht für den öffentlichen Gebrauch bestimmt sind. Das gibt dem Autor die Freiheit seine Implementierung flexibel auszugestalten und zu verändern, und schützt gleichzeitg den Anwender vor unerwarteten Effekten. JavaScript hat inzwischen auch ein Modul-System auf Sprachebene, daher kann man fragen, wieso es darüber hinaus auch noch das Shadow-DOM braucht. Der Grund ist, dass das DOM allen JavaScript-Modulen als eine globale, geteilte Ressource bereitgestellt wird, es durchtunnelt in gewisser Weise die native Datenkapselung. Das Shadow-DOM ermöglicht diese Trennung auch auf DOM-Ebene durchzusetzen. Man kommt übrigens auch weiterhin an die Implementierungs-Details heran, wenn Bedarf besteht, man muss nur das Warnschild ignorieren und unter das Flatterband hindurch schlüpfen.

> [Shadow-DOM](https://wiki.selfhtml.org/wiki/HTML/Web_Components/Shadow_DOM)? Du meinst, es ist von Vorteil, wenn mich eine Seite mit Registrierungszwang-Overlays quälen kann, ohne dass ich über Entwicklertools an die verursachenden DOM-Elemente gelange, um diese zu entfernen? Da hast du glaube ich etwas falsch verstanden (oder ich verstehe dich falsch). Du kannst jedenfalls mit deinen Entwicklerwerkzeugen das Shadow-DOM genau so frei einsehen und verändern, wie du es mit normalen DOM-Bäumen machen kannst. Das ganze Thema hat nichts mit DRM oder ähnlichem zu tun. Die zentrale Aufgabe des Shadow-DOMs ist eher vergleichbar mit der Trennung von öffentlicher Schnittstelle und Implementierung in objektorientierten Programmiersprachen. Wenn du eine Funktions-Bibliothek in PHP oder Java schreibst, hast du für gewöhnliche öffentliche und private Funktionen. Die öffentlichen sind für den Nutzer der Bibliothek bestimmt, die privaten Funktionen für die Entwickler der Bibliothek. Private Funktionen braucht man häufig als kleine Helferlein, die aber nicht direkt mit der fachlichen Zielsetzung der Bibliothek zu tun haben, oder von denen man glaubt, dass sie sich verhältnismäßig häufig ändern werden und flexibel sein müssen. Man möchte den Nutzer davor schützen, solche internen Funktionen zu benutzen, weil er damit beim nächsten Update womöglich riesigen Aufwand hätte seine Code-Basis anzupassen. Welche Funktionen der Nutzer risikolos benutzten soll, legt man in einer Schnittstellen beschreibung fest. Die Implementierung dieser Schnittstelle ist dann flexibel ausgestaltbar und änderbar. Das fällt in Programmiersprachen häufig unter den Schrimbegriff der Datenkapselung. Das Shadow-DOM dient einem ähnlichen Zweck: Der Autor einer Komponente oder eines Custom-Elements möchte den späteren Anwender davor schützen, sich auf Implementierungs-Details zu stürzen, die nicht für den öffentlichen Gebrauch bestimmt sind. Das gibt dem Autor die Freiheit seine Implementierung flexibel auszugestalten und zu verändern, und schützt gleichzeitg den Anwender vor unerwarteten Effekten. JavaScript hat inzwischen auch ein Modul-System auf Sprachebene, daher kann man fragen, wieso es darüber hinaus auch noch das Shadow-DOM braucht. Der Grund ist, dass das DOM allen JavaScript-Modulen als eine globale, geteilte Ressource bereitgestellt wird, es durchtunnelt in gewisser Weise die native Datenkapselung. Das Shadow-DOM ermöglicht diese Trennung auch auf DOM-Ebene durchzusetzen. Man kommt übrigens auch weiterhin an die Implementierungs-Details heran, wenn Bedarf besteht, man muss nur das Warnschild ignorieren und unter das Flatterband hindurch schlüpfen.