Custom Elements

[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.