heise.de: Lazy Loading Images mit Custom Elements

[Matthias Scharwies]

Servus!

heise.de berichtet

• Lazy Loading Images mit Custom Elements

Mir fehlen noch ein paar Beispiele für's Tutorial: HTML/Web_Components/custom_elements

Herzliche Grüße

Matthias Scharwies

[pl]

Ach heise berichtet so Einiges. Letztens war da sogar ein Artikel wo drinstand, daß man das Programmieren selber lernen muss. Gibt es Programmierer hier die das noch nicht wussten?

MfG

[Matthias Scharwies]

Servus!

Ach heise berichtet so Einiges.

Interessant, dass die Kommentare sich nicht so sehr um die neue Technik, sondern um die fehlende Notwendigkeit der Stock-Photos als Anreißer drehen.

Einige vermuten, dass der Artikel nur dazu dient, Best practice-Tipps für ein kostenpflichtiges Sonderheft abzufischen.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

• Lazy Loading Images mit Custom Elements

Fein, da hab ich ja den Intersection Observer wiedergefunden, nach dem ich für diesem Thread in meinem Kopf gesucht hatte.

LLAP 🖖

[Matthias Scharwies]

Servus!

@@Gunnar Bittersmann

Ich bin mir noch nicht sicher, welche Anwendungsfälle es geben könnte.

• die YouTube-Einbindung von Raoul

• evtl eine <x-lightbox> mit Buttons als Bilder Show?

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Ich bin mir noch nicht sicher, welche Anwendungsfälle es geben könnte.

• sortierbare Tabelle: Präsi ab Folie 65, Codepen (funktioniert in Chrome)

LLAP 🖖

[ThomasM]

Hallo Matthias,

Mir fehlen noch ein paar Beispiele für's Tutorial: HTML/Web_Components/custom_elements

Dieser Vortrag ist bald drei Jahre alt, aber vielleicht sind die Ideen zum Record-Widget und für SVG-Piecharts ansatzweise interessant.

Grüße,
Thomas

[Matthias Scharwies]

Servus!

@ThomasM @Gunnar Bittersmann

Vielen Dank. Das schau ich mir am Wochenende an. Am 23.10. Kommt FF63, der Web Components unterstützt. Bis dahin will ich die Artikel und Beispiele fertig haben.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Am 23.10. Kommt FF63, der Web Components unterstützt.

Hm, meine sortierbare Tabelle funktioniert nicht^[1] im 63.0b13. Meh. Unterstützt der Fuchs das is-Attribut nicht?

LLAP 🖖

---

1. „funktioniert“ hier im Sinne von: ist sortierbar. Der Fallback funktioniert natürlich: es ist eine Tabelle. ↩︎

[Orlok]

Hallo Gunnar

Hm, meine sortierbare Tabelle funktioniert nicht […]

Du verwendest veraltete Syntax.

Zum Beispiel entspricht die Methode document.registerElement(), mit der du dein Custom Element bekanntmachst, nicht mehr dem aktuellen Stand der Spezifikation.

---

Die Registrierung von Custom Elements erfolgt heute über eine CustomElementRegistry genannte Schnittstelle, die über die Eigenschaft window.customElements angesprochen werden kann und die mehrere einschlägige Methoden bereitstellt.

// Create custom element

class SortableTable extends HTMLTableElement { /* ... */ }


// Register custom element

customElements.define('sortable-table', SortableTable, {
    extends: 'table'
});

Die Registrierung des Elements erfolgt wie in dem Beispiel oben mit der Methode define, die als erstes Argument den Namen des Elements erwartet (siehe hierzu die Produktion PotentialCustomElementName). Als zweites Argument wird der Konstruktor übergeben und optional als drittes ein Objekt, über dessen Eigenschaft extends ein Element bestimmt werden kann, das erweitert werden soll.

Die Definition von Custom Elements erfolgt mittels Klassensyntax. Browser die Custom Elements unterstützen, können damit etwas anfangen. Vielleicht könnte man hier auch mit der Methode Reflect.construct() etwas basteln, aber selbst wenn das ginge, wäre es unnötig umständlich.

// Create custom element

class SortableTable extends HTMLTableElement {
    constructor() {
        super();

        // do something
    }
}

Wie üblich kann die Pseudomethode constructor der Klasse weggelassen werden, wenn an dieser Stelle keine Anweisungen notiert werden sollen. Wird sie notiert, muss vor dem Zugriff auf die Instanz, also auf this, explizit super aufgerufen werden.

// Get constructor of custom element

SortableTable === customElements.get('sortable-table'); // true

Neben der Methode define gibt es auch noch eine Methode namens get, die den Namen eines Custom Elements erwartet und wenn vorhanden den dazugehörigen Konstruktor zurückgibt.

// Custom element definition using class expression

customElements.define(
    'my-element',
    class extends HTMLElement { /* ... */ }
);

Das ist zum Beispiel dann von Nutzen, wenn für die Erzeugung des Custom Elements wie in dem Beispiel oben ein Klassenausdruck und keine Deklaration verwendet wurde.

Schließlich gibt es noch eine Methode customElements.whenDefined(elementName), die ein Promise zurückgibt, das eingelöst wird wenn das Element erfolgreich registriert wurde.

// Important lifecycle callbacks

class MyElement extends HTMLElement {

    connectedCallback() {
        console.info('element is connected to DOM tree');
    }

    disconnectedCallback() {
        console.info('element was removed from DOM tree');
    }

}

Neben dem Konstruktor gibt es noch sogenannte Lifecycle Callbacks, also Funktionen, die bei bestimmten das Custom Element betreffenden Ereignissen aufgerufen werden. Die beiden wichtigsten sind oben notiert. connectedCallback wird aufgerufen, wenn das Element ins DOM gehängt wurde, und disconnectedCallback, wenn es aus dem DOM entfernt wurde.

class MyElement extends HTMLElement {

    static get observedAttributes() {
        return ['my-attribute'];
    }

    attributeChangedCallback(attributeName, oldValue, newValue) {
        if (attributeName === 'my-attribute') {

            // do something
        }
    }

}

Das Handling von Attributen des Elements erfolgt wie in dem Beispiel oben. Über den statischen Getter observedAttributes wird eine Liste der Attribute bereitgestellt, die überwacht werden sollen.

Wird ein Attribut gesetzt, dann wird die Methode attributeChangedCallback aufgerufen, der als erstes Argument der Name des geänderten Attributs und danach der alte und der neue Attributwert übergeben werden.

Vielleicht hilft dir das weiter.

Viele Grüße,

Orlok

[Felix Riesterer]

Lieber Orlok,

Zum Beispiel entspricht die Methode document.registerElement(), mit der du dein Custom Element bekanntmachst, nicht mehr dem aktuellen Stand der Spezifikation.

mir waren Custom Elements schon immer suspekt. Ich verwende sie einfach nicht. Es geht immer auch anders.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

mir waren Custom Elements schon immer suspekt. Ich verwende sie einfach nicht. Es geht immer auch anders.

„Mir waren CSS Grids schon immer suspekt. Ich verwende sie einfach nicht. Es geht immer auch anders: Tabellenlayout.“

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

„Mir waren CSS Grids schon immer suspekt. Ich verwende sie einfach nicht. Es geht immer auch anders: Tabellenlayout.“

ich fühle mich falsch verstanden. Aber vielleicht habe ich einfach falsch verstanden, worum es hier überhaupt geht, und werde entsprechend technisch beantwortet...

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

mir waren Custom Elements schon immer suspekt. Ich verwende sie einfach nicht. Es geht immer auch anders.

Man kann auch das Kapseln von wiederverwendbarem Code in selbst geschriebene Funktionen meiden und alles mit goto machen. Aber ob man damit glücklich wird?

Wenn du möchtest, kannst du dir mal Angular anschauen, und da ein bisschen durch das Tutorial schauen. Angular verwendet recht konsequent das Komponenten-Prinzip, wenn auch nicht in der Ausführung "Web Components". Sicherlich, wenn man nur etwas Javascript zur Seite hinzufügen möchte, um die eine oder die andere Funktionalität zu ergänzen, dann ist die Verwendung eines Frameworks, das für die Erstellung ganzer Anwendungen gedacht ist, nicht wirklich angebracht. Aber für diese "nur-etwas-Javascript"-Fälle sind die Web Components nicht unbedingt gedacht. Für Desktop-Anwendungen ist es hingegen seit sehr langer Zeit gang und gäbe, komplexe Elemente der Benutzeroberfläche in selbst definierten Komponenten zu kapseln. Natürlich ist das oft nur eine Ansammlung der bekannten Dinge plus Code, zusammengefasst unter einer Haube, und man kann das auch alles einzeln notieren. Aber übersichtlicher wird das am Ende nicht unbedingt. Es ist schon von Vorteil, wenn die Komplexität der Komponente hinter einer einzelnen Zeile Code verschwindet, zumindest an der Stelle, an der sie im restlichen Kontext eingebunden ist.

Auch im Webumfeld, wenn der Anwendungsfall noch nicht lautstark nach einer Webanwendung ruft (also das, was man auf dem Desktop als Programm mit GUI erzeugt hätte), lassen sich Komponenten nutzen. Beispielsweise sollen Daten in Form eines Tortendiagramms dargestellt werden. Kann man machen, indem man einen Canvas nimmt und etwas drauf herummalt, oder ein SVG nimmt und ein paar Deklarationen für die geometrischen Gebilde einfügt, oder vielleicht mit CSS aus ein paar Rechtecken Tortenstücke zaubert und im Kreis anordnet. Oder man erstellt sich daraus eine Komponente, der man nur noch die Daten übergibt.

Wenn du immer wieder Javascript an eins der HTML-Elemente anflanschst, oder gar mehrere HTML-Elemente in immer derselben Anordnung zuzüglich Javascript-Code eine wiederkehrende Einheit bilden, dann kann man darüber nachdenken, daraus eine Komponente zu erstellen. Die ist dann einfacher eingebaut als der komplexe HTML-Code plus Eventhandlerverdrahtung.

Komponenten sind also sehr stark darin, wiederverwendbaren Dingen einen Rahmen zu geben.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Es ist schon von Vorteil, wenn die Komplexität der Komponente hinter einer einzelnen Zeile Code verschwindet, zumindest an der Stelle, an der sie im restlichen Kontext eingebunden ist.

Es ist auch von Vorteil, wenn die Komplexität des User-Interface aus dem DOM verschwindet und im Shadow-DOM der Komponente eingebunden ist.

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

Es ist auch von Vorteil, wenn die Komplexität des User-Interface aus dem DOM verschwindet und im Shadow-DOM der Komponente eingebunden ist.

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?

Wenn man das Shadow-DOM bemühen muss, hat man dann nicht ein Problem bei der Namespace-Struktur gemacht, oder diese überhaupt nicht erst verwendet?

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

Es ist auch von Vorteil, wenn die Komplexität des User-Interface aus dem DOM verschwindet und im Shadow-DOM der Komponente eingebunden ist.

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?

Nicht alles kann ins Shadow DOM wandern. Das muss ja auch mit dem DOM der Seite verbunden sein. Mindestens das Container-Element bleibt weiterhin erhalten und kann beeinflusst werden. CSS-Regeln gelten prinzipiell auch für den Inhalt. allerdings kann man im Custom Element auch alle Eingenschaften auf den Initialwert zurücksetzen. Eine konkrete Beeinflussung à la Selector my-element p zieht allerdings nicht (in meinem Versuch).

Wenn man das Shadow-DOM bemühen muss, hat man dann nicht ein Problem bei der Namespace-Struktur gemacht, oder diese überhaupt nicht erst verwendet?

Vielleicht versteh ich grad nicht, was du meinst. Namensräume in HTML? Zumindest ist es nach meinem Verständnis so, dass ein Shadow DOM einen eigenen Scope darstellt, und man darin Dinge verwenden kann, die mit dem globalen Scope nicht kollidieren, beispielsweise IDs und Style-Regeln.

dedlfix.

[Felix Riesterer]

Lieber dedlfix,

Mindestens das Container-Element bleibt weiterhin erhalten und kann beeinflusst werden.

das beruhigt mich jetzt. Ehrlich!

Vielleicht versteh ich grad nicht, was du meinst. Namensräume in HTML?

Exakt. Wenn ich mit ID als Namensraum arbeite, dann kollidiert das eventuell mit einem anderen Element, das den identischen ID-Wert hat. Arbeite ich dagegen mit einem passenden data-*-Attribut anstelle einer ID, kann ich die Idee von Namensräumen wieder vollumfänglich verwenden. Und wenn sich alle Komponenten daran halten, dann sollte das ohne Kollisionen klappen.

Aber das werden sie zur Zeit nicht tun, da wir einen ID-Selektor einfach viel schneller notieren, als einen Attribut-Selektor...

Zumindest ist es nach meinem Verständnis so, dass ein Shadow DOM einen eigenen Scope darstellt, und man darin Dinge verwenden kann, die mit dem globalen Scope nicht kollidieren, beispielsweise IDs und Style-Regeln.

Eben. Mit sauber getrennten Namensräumen bräuchte es das nicht.

Liebe Grüße,

Felix Riesterer.

[1unitedpower]

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.

[Gunnar Bittersmann]

@@Felix Riesterer

Shadow-DOM? Du meinst, es ist von Vorteil, wenn mich eine Seite mit Registrierungszwang-Overlays quälen kann

Natürlich nicht. Ich halte den ersten Absatz im Wiki-Artikel nicht für sonderlich gelungen, um in das Thema einzuführen. Den Teufel eines potentiellen Missbrauchs an die Wand zu malen schreckt eher ab, wie in deinem Fall. Der Einleitung des Artikels sollte vielleicht diesbezüglich mal überarbeitet werden.

---

Die Wegkapselung ins Shadow-DOM hast du auch bei nativen HTML-Elementen wie progress und meter, die unter der Haube zumindest aus einem Element fürs Gesamte und einem für den jeweiligen Teil bestehen. (In Browsern kommt man über Pseudoelemente ggfs. auch ran, um diese zu stylen.)

Und bei <input type="range">: die Bahn und der Schiebeknopf. (Die ursprünglich vorgesehene Idee, dass wenn man dem Ding per CSS eine quadratische Abmessung verpasst, ein Drehknopf angezeigt wird, hat wohl nie ein Browser implementiert?)

Und noch mehr bei audio und video, wo es neben Schiebereglern für die Zeitachse und die Lautstärke noch Knöpfe für Start, Stop, Pause u.v.a.m. gibt.

---

Custom elements machen total Sinn für Dinge, die es in HTML geben sollte, aber nicht gibt. Das Beispiel einer sortierbaren Tabelle hatte ich genannt, was irgendwann in nativem HTML auch mal vorgesehen war (<table sortable>), aber nicht inplementiert wurde.

Oder bspw., um <input type="password"> vernünftig umzusetzen – mit Umschaltung der Nichtanzeige/Anzeige des Passworts. Was Browser eigentlich nativ können sollten, so wie es IE und Edge ansatzweise tun. (Sie zeigen das Passwort, solange man den Knopf drückt. Besser wäre ein Umschaltknopf.)

LLAP 🖖

[Felix Riesterer]

Lieber dedlfix,

Komponenten sind also sehr stark darin, wiederverwendbaren Dingen einen Rahmen zu geben.

ist "Komponente" gleich Custom Element(s)?

Man kann auch das Kapseln von wiederverwendbarem Code in selbst geschriebene Funktionen meiden und alles mit goto machen. Aber ob man damit glücklich wird?

Inwiefern siehst Du eine Parallele zwischen goto und "keine Custom Elements"?

Aus meiner Sicht benötige ich keine selbstgebauten HTML-Elemente (lies: custom element wie z.B. <x-l> bei Gedichtzeilen), seit es diese data-*-Attribute gibt. Der Vorrat an Elementen in HTML ist so umfangreich, dass man mit den gegebenen Elementen vorzüglich semantischen Code schreiben kann, der unter Zuhilfenahme eines data-*-Attributs zu einer "Komponente" umfunktioniert werden kann.

Wenn du möchtest, kannst du dir mal Angular anschauen,

Habe Janosch mit Angular arbeiten sehen. Die verwenden TypeScript. Das wird zu VanillaJS compiliert. Feine Sache, aber für meine Zwecke zu groß.

Für Desktop-Anwendungen ist es hingegen seit sehr langer Zeit gang und gäbe, komplexe Elemente der Benutzeroberfläche in selbst definierten Komponenten zu kapseln. Natürlich ist das oft nur eine Ansammlung der bekannten Dinge plus Code, zusammengefasst unter einer Haube, und man kann das auch alles einzeln notieren. Aber übersichtlicher wird das am Ende nicht unbedingt. Es ist schon von Vorteil, wenn die Komplexität der Komponente hinter einer einzelnen Zeile Code verschwindet, zumindest an der Stelle, an der sie im restlichen Kontext eingebunden ist.

Vielleicht bin ich gerade borniert, aber klingt das nach einem zwingenden Argument für Custom Elements? Diese "Ansammlung der bekannten Dinge plus Code" klingt eher sogar nach Genuine HTML Elements... oder habe ich das alles einfach nur falsch verstanden?

Auch im Webumfeld, wenn der Anwendungsfall noch nicht lautstark nach einer Webanwendung ruft (also das, was man auf dem Desktop als Programm mit GUI erzeugt hätte), lassen sich Komponenten nutzen.

Komponenten, Komponenten - ich lese nur Komponenten, nichts aber über Custom Elements! Reden wir einfach nur aneinander vorbei?

Beispielsweise sollen Daten in Form eines Tortendiagramms dargestellt werden. Kann man machen, indem man einen Canvas nimmt und etwas drauf herummalt, oder ein SVG nimmt und ein paar Deklarationen für die geometrischen Gebilde einfügt, oder vielleicht mit CSS aus ein paar Rechtecken Tortenstücke zaubert und im Kreis anordnet. Oder man erstellt sich daraus eine Komponente, der man nur noch die Daten übergibt.

Canvas ist kein Custom Element, ebenso wenig ein <img src="diagramm.svg" alt="Diagramm">...

Wenn du immer wieder Javascript an eins der HTML-Elemente anflanschst, oder gar mehrere HTML-Elemente in immer derselben Anordnung zuzüglich Javascript-Code eine wiederkehrende Einheit bilden, dann kann man darüber nachdenken, daraus eine Komponente zu erstellen. Die ist dann einfacher eingebaut als der komplexe HTML-Code plus Eventhandlerverdrahtung.

Das ist mir klar. Anderswo nennt man so etwas ein Widget. Von mir aus nenne es "Komponente". Aber muss die mit einem (oder mehreren) Custom Elements realisiert werden?

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

Komponenten sind also sehr stark darin, wiederverwendbaren Dingen einen Rahmen zu geben.

ist "Komponente" gleich Custom Element(s)?

Web Components nennt sich der Standard und der ermöglicht Komponenten zu erstellen, die dann als Custom Elements neben den Standard-Elementen von HTML für das aktuelle Dokument hinzugefügt werden können. Man kann die Begriffe größtenteils synonym verwenden, meine ich, zumindest für die allgemeine Erklärung der Funktionsweise.

Man kann auch das Kapseln von wiederverwendbarem Code in selbst geschriebene Funktionen meiden und alles mit goto machen. Aber ob man damit glücklich wird?

Inwiefern siehst Du eine Parallele zwischen goto und "keine Custom Elements"?

Die Umständlichkeit beim Lösen komplexer Probleme wollte ich vergleichen. Der Prozessor kennt am Ende nur Sprungbefehle, aber in Hochsprachen steht es meist außer Frage, Funktionen zu verwenden, statt mit Sprungbefehlen durch den Code zu navigieren. Nicht alles was hinkt ist ein Vergleich. Das sollte ein etwas plakativer Einstieg werden.

Aus meiner Sicht benötige ich keine selbstgebauten HTML-Elemente (lies: custom element wie z.B. <x-l> bei Gedichtzeilen), seit es diese data-*-Attribute gibt. Der Vorrat an Elementen in HTML ist so umfangreich, dass man mit den gegebenen Elementen vorzüglich semantischen Code schreiben kann, der unter Zuhilfenahme eines data-*-Attributs zu einer "Komponente" umfunktioniert werden kann.

Dagegen ist nichts grundsätzliches einzuwenden. Komponenten / Custom Elements sollen nichts ersetzen, sie bieten aber zusätzliche Möglichkeiten an, die bei steigender Komplexität ihre Vorteile ausspielen.

Für Desktop-Anwendungen ist es hingegen seit sehr langer Zeit gang und gäbe, komplexe Elemente der Benutzeroberfläche in selbst definierten Komponenten zu kapseln. Natürlich ist das oft nur eine Ansammlung der bekannten Dinge plus Code, zusammengefasst unter einer Haube, und man kann das auch alles einzeln notieren. Aber übersichtlicher wird das am Ende nicht unbedingt. Es ist schon von Vorteil, wenn die Komplexität der Komponente hinter einer einzelnen Zeile Code verschwindet, zumindest an der Stelle, an der sie im restlichen Kontext eingebunden ist.

Vielleicht bin ich gerade borniert, aber klingt das nach einem zwingenden Argument für Custom Elements? Diese "Ansammlung der bekannten Dinge plus Code" klingt eher sogar nach Genuine HTML Elements... oder habe ich das alles einfach nur falsch verstanden?

Nicht zwingend, aber es ist meist übersichtlicher zum Beispiel für ein Formular mit 5 Eingabeelementen (Input nebst Label und einer Möglichkeit zur Anzeige von Validierungsfehlermeldungen) 5 Zeilen im Code stehen zu haben als 5 × 10 Zeilen, die sich bis auf das Name-Attribut wiederholen. Die 10 Zeilen stehen dann einmalig an anderer Stelle, plus etwas Overhead, um sie als Custom Element zu registrieren.

Komponenten, Komponenten - ich lese nur Komponenten, nichts aber über Custom Elements! Reden wir einfach nur aneinander vorbei?

Nein, alles gut, das spielt alles zusammen. Angular verwendet meines Wissens noch keine Custom Elements, aber so wie man dort mit Komponenten umgeht, wären das gute Kandidaten, sie über Custom Elements ins HTML einzubinden statt wie derzeit proprietär. (Inwieweit da Pläne existieren, weiß ich aber nicht.)

Beispielsweise sollen Daten in Form eines Tortendiagramms dargestellt werden. Kann man machen, indem man einen Canvas nimmt und etwas drauf herummalt, oder ein SVG nimmt und ein paar Deklarationen für die geometrischen Gebilde einfügt, oder vielleicht mit CSS aus ein paar Rechtecken Tortenstücke zaubert und im Kreis anordnet. Oder man erstellt sich daraus eine Komponente, der man nur noch die Daten übergibt.

Canvas ist kein Custom Element, ebenso wenig ein <img src="diagramm.svg" alt="Diagramm">...

Da hast du recht, aber das Canvas-Element allein reicht ja noch nicht. Da kommt noch Code hinzu, der die Tortenstücke auf den Canvas zeichnet. Aus der semantischen Sicht meines Anwendungsfalls ist "Canvas und ein Haufen Code und Zahlen" nicht weiter aussagekräftig. "Tortendiagramm mit den Werten …" ist es aber schon eher und damit ist der Sinn dahinter für den Programmierer/HTML-Codierer (hoffentlich) leichter verständlich. Aus der Sicht von HTML hingegen ist "Tortendiagramm" bedeutungslos, aber der Browser bekommt ja letztlich seinen Canvas (gekapselt in meinem Custom Element) und hat damit die Semantik, die er versteht.

Das Image ist natürlich ein natives HTML-Element, aber wenn man so will ist ein SVG-Bild auch nichts anderes als eine Komponente und wenn sie als <svg> eingebunden wird, ähnlich wie ein Custom Element. Aufgrund seiner allgemeinen Bedeutung ist es aber ein Standard-Element geworden.

Wenn du immer wieder Javascript an eins der HTML-Elemente anflanschst, oder gar mehrere HTML-Elemente in immer derselben Anordnung zuzüglich Javascript-Code eine wiederkehrende Einheit bilden, dann kann man darüber nachdenken, daraus eine Komponente zu erstellen. Die ist dann einfacher eingebaut als der komplexe HTML-Code plus Eventhandlerverdrahtung.

Das ist mir klar. Anderswo nennt man so etwas ein Widget. Von mir aus nenne es "Komponente". Aber muss die mit einem (oder mehreren) Custom Elements realisiert werden?

Muss nicht, siehe Angular, da klappt das auch ohne. Nur sind die umschließenden Elemente der Komponenten dann für die Browser unbekannte Elemente, die nicht zum Standard gehören, aber wegen Fehlertoleranz der Browser ignoriert werden. Das Javascript von Angular sorgt dafür, dass sie im Browser passend eingebettet werden. Als Custom Element gäbe es aber dazu die Vorteile, für die man den Web Components Standard aufgesetzt hat, wie zum Beispiel das von Gunnar angeführte Verstecken der Implementationsdetails im Shadow DOM und damit ein aufgeräumtes und übersichtlicheres DOM.

dedlfix.

[Matthias Scharwies]

Servus!

Servus!

@ThomasM @Gunnar Bittersmann

Vielen Dank. Das schau ich mir am Wochenende an.

Habe mir grad die Präsentation angeschaut: Ein Überblick zu Web Components

Das mit den pie-charts hatte Lea Verou mal mit <circle> und <stroke-dasharray> realisiert. Ich hatte beim Nachbau aber ziemliche Artefakte im Rendering.

Besonders das Element <tm-safety> mit Staplerfahrer Klaus hat es mir angetan!

Nochmals vielen Dank!

Herzliche Grüße

Matthias Scharwies

[Tabellenkalk]

Hallo,

"Bin ich denn der Einzigste hier, wo Deutsch kann?"

Na, i bi a no da!

Gruß
Kalk