HTML-Tags können direkt selbst erstellt und verwendet werden

 (maurycyz.com)
3 Punkte von GN⁺ 2025-12-30 | 1 Kommentare | Auf WhatsApp teilen
  • In HTML können nicht erkannte Tag-Namen verwendet werden, und der Browser behandelt sie dann als normale Elemente
  • Wenn dieser Tag-Name in CSS als Selektor angegeben wird, sind Styling und Anzeigesteuerung möglich
  • Verwendet man Namen mit Bindestrich (-), lässt sich ein Konflikt mit zukünftigen HTML-Standards vermeiden
  • Statt oder können bedeutungsvolle benutzerdefinierte Tags verwendet werden, was die Lesbarkeit des Codes erhöht
  • Selbst in komplex verschachtelten Strukturen lässt sich die Struktur allein anhand der Tag-Namen leichter erfassen, was die Wartung erleichtert

Einsatz benutzerdefinierter HTML-Tags

  • Browser rendern unbekannte Tags wie normale Block-Elemente

    • Das ist ein in der HTML-Spezifikation festgelegtes normales Verhalten; mit CSS kann das Erscheinungsbild visuell gesteuert werden
    • Als Beispiel kann ein Tag wie `` definiert und in CSS in der Form cool-thing { ... } gestaltet werden

  • Wenn der Tag-Name einen Bindestrich (-) enthält, besteht keine Gefahr, dass er künftig dem HTML-Standard hinzugefügt wird, sodass kein Kollisionsrisiko besteht

    • Beispiele: , usw.

Verbesserte Lesbarkeit und Struktur

  • Wenn statt oder Tags mit aussagekräftigen Namen verwendet werden, ist der Code leichter zu verstehen
    • So kann zum Beispiel statt auch verwendet werden
  • In verschachtelten ``-Strukturen ist es schwierig, die Position schließender Tags zu erkennen, aber mit expliziten Tag-Namen wird die Struktur klarer
    • Wenn intern aus, `` usw. besteht, ist die DOM-Struktur intuitiv nachvollziehbar

Beispielcode

  • Herkömmlicher Ansatz 
    
  Hello, World!
  • Ansatz mit benutzerdefiniertem Tag 
    
  Hello, World!
    • In CSS kann dann ein Stil wie cool-thing { display: block; font-weight: bold; text-align: center; ... } definiert werden

Fazit

  • Wenn die vom HTML-Standard erlaubte flexible Definition von Tags genutzt wird, lässt sich strukturelles Markup mit hoher Lesbarkeit schreiben
  • Wenn es jedoch bereits ein vorhandenes, semantisch passendes Tag gibt, sollte dieses bevorzugt verwendet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-30
Hacker-News-Kommentare

  • Es wird betont, dass kein nicht erkanntes Tag ist Der Autor verweist auf seinen [Blogbeitrag](https://dashed-html.github.io) und erklärt, dass als HTMLUnknownElement behandelt wird, bis WHATWG es als neues Element hinzufügt, während ein **gültiges HTMLElement** ist und sich daher gut für Layout und Styling eignet. Wenn es über die JavaScript Custom Elements API erweitert wird, wird es zu einem **definierten Custom Element**. Das ist Standardverhalten in allen Browsern, und auch der W3C HTML Validator erkennt Custom Elements mit Bindestrich als HTMLElement an. Allerdings wird die Regel `[hidden]{display:none}` aus dem Standard-UA-Stylesheet nicht mitvererbt und muss daher selbst gesetzt werden. Dass standardmäßig display:block ist, liegt ebenfalls am UA-Stylesheet, daher muss man bei Custom Elements die display-Eigenschaft selbst setzen. Mit den CSS-Selektoren :defined und :not(:defined) lassen sich definierte und nicht definierte Elemente unterscheiden. Auch Declarative Shadow DOM (``) erzeugt auf die gleiche Weise nicht definierte Custom Elements.

    • Dagegen wird eingewendet, dass es in Chromium nicht am UA-Stylesheet liegt, sondern daran, dass hidden ein HTML-Präsentationsattribut (presentation attribute) ist. Das UA-Stylesheet werde auch auf Custom Elements unverändert angewendet, eine [hidden]-Regel existiere dort nicht. hidden sei ein Beispiel dafür, dass ein Attribut selbst stilistisch interpretiert wird, ähnlich wie align="right".
    • Es wird bedauert, dass man statt des Bindestrichs (-) nicht auch einen Doppelpunkt (:) verwenden kann, womit sich XML-Namespaces natürlicher hätten integrieren lassen. Erwähnt wird auch, dass nginx oder apache Doppelpunkte in Bindestriche hätten umwandeln können. Mit „Wir können nicht nach 1999 zurück“ endet der Kommentar in nostalgischem Ton.
    • Es wird gefragt, warum diese Vorgehensweise nicht die gängige Praxis ist.

  • Es wird darauf hingewiesen, dass die verschachtelte -Struktur im Beispielcode übertrieben ist. Stattdessen wird vorgeschlagen, **semantische Tags** wie , und zu verwenden.

    • Es wird angemerkt, dass Custom Tags im Gegensatz zu Klassenattributen nur einen einzigen Namen haben können. Klassen können mehrfach vergeben werden und sind ungeordnet, verschachtelte Custom Elements erzwingen dagegen eine Reihenfolge, wodurch sich dieselbe Ausdrucksweise schwerer abbilden lässt.
    • Es wird analysiert, dass nicht „div soup“ das eigentliche Problem ist, sondern eine HTML-Architekturentscheidung, die Struktur und Styling eng miteinander koppelt. 1996 sei das nachvollziehbar gewesen, heute jedoch nicht mehr.

  • Jemand teilt seine Erfahrung aus 3 bis 4 Jahren Arbeit mit Custom Elements. Die Idee sei clever, in der Praxis aber knifflig. Bei zu vielen Custom Tags leide die Lesbarkeit, und die Unterscheidung zwischen Block- und Inline-Elementen werde schwieriger. Als ausgewogener Ansatz werden Standard-Tags beibehalten und Custom Tags nur für komponentenartige Elemente wie oder verwendet. Untergeordnete Teile werden über slot-Attribute wie in `` unterschieden. Klassen werden nur für Modifikationen und Anpassungen genutzt, während die Struktur bevorzugt über Slots ausgedrückt wird.

    • Es wird Interesse an einem ausgewogenen Web-Components-Ansatz geäußert und nach Beispielen oder Toolsets gefragt. Vorgestellt wird das eigene Projekt Good.HTML, das Autohooks, Interpolation auf Basis von Template Literals und eine geordnetere Komponentenstruktur unterstütze. Hinzugefügt wird, dass selbstschließende Custom Elements wie < !app-header /> mit einem Kommentar-Knoten-Trick umgesetzt wurden.
    • Es wird gefragt, ob man zur Auswahl per CSS anhand des slot-Attributs einfach div[slot="hero-blurb"] schreiben könne.
    • Es wird erwähnt, dass dieses Muster an die Block-Element-Struktur von BEM erinnere.

  • Standardmäßig verhalten sich Custom Tags wie ``. Falls nötig, kann man ihr Verhalten über die Custom Element API definieren.

    • Jemand berichtet, bereits 2014 Custom Elements breit eingesetzt zu haben, und äußert Bedauern darüber, dass React dominant geworden ist. Für die meisten Nutzer wäre eine Kombination aus HTML und Custom Elements seiner Meinung nach besser gewesen als ein SPA.
    • Es wird empfohlen, zuerst semantische Elemente zu nutzen und Custom Elements nur bei Bedarf einzusetzen. Als Beispiel wird das eigene Projekt Hypalink genannt, verbunden mit dem Hinweis, dass Web Components unterschätzt würden.

  • Es wird ein Custom Tag namens vorgestellt, das als Gegenstück zu dient. Damit lassen sich bestimmte Bereiche ausblenden, wenn JS deaktiviert ist. Ein Projektlink wird geteilt.

    • Es wird vorgeschlagen, dass sich derselbe Effekt auch rein mit CSS über @media (scripting) erreichen lasse. Dazu wird ein Verweis auf die MDN-Dokumentation ergänzt.

  • Jemand berichtet, früher das aus Browsern entfernte ``-Tag selbst nachgebaut zu haben. Es wurde mit jQuery und visibility-Manipulation umgesetzt, und die Person war überrascht, dass Browser beliebige Tags zulassen. Da der Code nur etwa zehn Zeilen umfasste, wurde er nicht veröffentlicht, aber es gebe vermutlich viele ähnliche Versuche.

    • Es wird erklärt, dass die meisten Browser `` tatsächlich nie implementiert haben und nur Firefox und Opera es bis 2013 unterstützten.
    • Es wird weiterhin Bedauern über das Verschwinden von Flash geäußert.
    • Es wird darauf hingewiesen, dass sich der ``-Effekt auch nur mit CSS erzeugen lässt, und ein Codebeispiel wird geteilt. Mit dem Selektor blink statt .blink lasse sich der Effekt direkt auf das Tag anwenden.
    • Es wird begrüßt, dass Funktionen wie `` verschwunden sind, weil ein solches Verhalten für ein einfaches HTML-Element zu viel semantische Bedeutung mitbringe.

  • Es wird angemerkt, dass Beispiele wie und durch echte HTML-Tags ersetzt werden könnten. Die Verwendung von , und `` sei angemessener.

    • Ergänzt wird, dass man bei vordefinierten HTML-Tags auch von der Standard-Stylisierung des Browsers profitiert.

  • Custom Tags werden standardmäßig wie `` inline gerendert, aber man kann per CSS eine Standard-display-Eigenschaft festlegen. Früher habe man sie wegen Namespace-Problemen gemieden, doch seit der Standard Bindestriche (-) erlaubt, bestehe kein Kollisionsrisiko mehr. Sie funktionieren auch in CSS-Selektoren problemlos und lassen sich mit querySelector ansprechen. Der Eindruck sei, dass sich auch ohne Frameworks wie Vue mit modernem HTML bereits genug ausdrücken lässt.

    • Ergänzend wird erwähnt, dass nicht standardisierte Elemente mit Bindestrich nicht als HTMLUnknownElement, sondern als HTMLElement behandelt werden. Das sei bewusst so gestaltet, damit sich beim späteren Upgrade die Prototyp-Kette natürlich erweitern kann.

  • Um allen Custom Elements einen Standardstil zu geben, könne man Folgendes verwenden:

    :where(:not(:defined)) {
  display: block;
}
    • Es wird Begeisterung und Dank dafür ausgedrückt, genau nach dieser Methode gesucht zu haben.

  • Es wird daran erinnert, dass ältere IE-Versionen HTML5-Tags nicht erkannten, weshalb der Kommentator das um 2010 mit einem eigenen Skript gelöst habe. Wenn ein Tag per JS einmal erzeugt wurde, erkannte IE es danach, und auch nach dem Löschen blieb es funktionsfähig. So habe man erkannt, dass sich auf diese Weise auch beliebige Tags rendern lassen. Dazu wird der damalige Blogbeitrag geteilt.

    • Ergänzt wird, dass das populäre html5shim auf dieselbe Weise funktionierte.