1 Punkte von GN⁺ 9 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • `` ist ein HTML-Element, das semantisch eine Liste von Name-Wert-Paaren ausdrückt und sich für UI-Muster wie Ausstattungsmerkmale, Abrechnungsposten oder technische Glossare eignet
  • Eine Beschreibungsliste ist so aufgebaut, dass Namen** und ** Werte innerhalb von `` platziert werden; einem Namen können auch mehrere Werte zugeordnet sein
  • Wenn zusammengehörige und zum Styling gruppiert werden müssen, darf laut Spezifikation nur ein ``-Wrapper die Gruppe umschließen
  • Mit allein verschachtelten ist es für assistive Technologien schwerer, das Listenmuster zu erkennen, während Navigationsvorteile wie Elementanzahl, aktuelle Position und Überspringen der Liste bietet
  • Selbst unterschiedlich geformte Daten zu Werten, Fähigkeiten und Aktionen wie in einem Dungeons & Dragons-Stat-Block lassen sich in Beschreibungsliste aufteilen, was ihre Vielseitigkeit gut zeigt

Welches Muster `` ausdrückt

  • `` ist ein HTML-Element zur Darstellung einer Liste von Name-Wert-Paaren und verleiht einem in Web-UIs immer wieder auftretenden Muster Semantik
  • Typische Kandidaten sind Strukturen, in denen Name und Wert zusammengehören, etwa Ausstattungsmerkmale einer Unterkunft, einzelne Posten einer Monatsmiete oder technische Glossare
  • ist kein einzelnes Element, sondern bildet mit den drei Elementen, und eine Name-Wert-Gruppe
  • Vor HTML5 wurde `` als definition list bezeichnet und war ursprünglich dafür gedacht, Glossare aus Begriffen und Definitionen darzustellen

Grundstruktur einer Beschreibungsliste

  • , , ``

    • **** umschließt die gesamte Beschreibungsliste und übernimmt eine ähnliche Rolle wie oder `` für eine ganze Liste
    • ** steht für den Beschreibungsterm (description term) und repräsentiert den Namen, ** für das Beschreibungsdetail (description detail) und repräsentiert den Wert
    • und waren früher auch als definition term bzw. definition detail bekannt
    • Die Grundstruktur besteht aus einem einzelnen , auf das ein einzelnes folgt

	Title
	Designing with Web Standards

  • Mehrere Name-Wert-Paare

    • Um in derselben Liste weitere Name-Wert-Paare hinzuzufügen, werden einfach neue - und -Elemente nacheinander platziert

	Title
	Designing with Web Standards
	Publisher
	New Riders Pub; 3rd edition (October 19, 2009)

  • Mehrere Werte für einen Namen

    • Ein einzelnes ** kann mehrere **-Werte haben
    • So lässt sich direkt eine Struktur ausdrücken, in der einem Namen mehrere Werte zugeordnet sind, etwa bei einem Buch mit mehreren Autorinnen und Autoren

	Title
	Designing with Web Standards
	Author
	Jeffrey Zeldman
	Ethan Marcotte
	Publisher
	New Riders Pub; 3rd edition (October 19, 2009)

  • Wrapper fürs Styling

    • Wenn zusammengehörige und zum Zweck des Stylings gruppiert werden müssen, kann ein ``-Wrapper verwendet werden
    • Laut Spezifikation ist das einzige Wrapper-Element, das eine/``-Gruppe umschließen darf
    • Weitere zulässige Strukturen und Einschränkungen finden sich in der ``-Dokumentation von MDN oder in der HTML-Spezifikation

		Title
		Designing with Web Standards

		Author
		Jeffrey Zeldman
		Ethan Marcotte

Warum Semantik wichtig ist

  • Name-Wert-Gruppen lassen sich visuell auch nur mit verschachtelten `` erstellen, für Browser oder assistive Technologien ist es dann jedoch schwerer, sie als Listenmuster zu erkennen
  • Die Wahl semantischer Elemente kann daran ausgerichtet werden, ob Nutzende einen praktischen Vorteil haben, wenn Computer das betreffende Muster erkennen
  • Mit `` können Nutzerinnen und Nutzer von Screenreadern eine Liste von Name-Wert-Gruppen leichter navigieren
    • Sie können die Anzahl der Name-Wert-Gruppen in der Liste erfahren
    • Sie können erkennen, an welcher Position sie sich innerhalb der Liste befinden
    • Wenn die Liste nicht relevant ist, können sie sie als einen Block überspringen
  • In einer verschachtelten -Struktur werden Name und Wert jeweils eher wie unabhängige Textknoten behandelt, während denselben Informationen strukturelle Semantik verleiht
  • Diese Vorteile werden bei Verwendung von `` in den meisten Kombinationen aus Browser und Screenreader tatsächlich geboten
  • Da die Unterstützung für jedoch noch nicht überall einheitlich ist, kann man auch andere Elemente wie wählen, bis sich die Unterstützung verbessert, wenn eine Fallback-Erfahrung mit unabhängigen Textknoten nicht ausreicht

Beispiel: Dungeons-&-Dragons-Stat-Block

  • Ein Stat-Block aus Dungeons & Dragons ist ein gutes Beispiel mit vielen Name-Wert-Paaren, und innerhalb eines einzelnen Stat-Blocks lassen sich mehrere Kandidaten für Beschreibungsliste finden
  • Basiswerte wie Armor Class, Hit Points und Speed, Attributswerte wie STR und DEX, ergänzende Angaben wie Senses, Languages und Challenge sowie Traits und Actions lassen sich jeweils in eigene Beschreibungslisten aufteilen
  • Auch visuell unterschiedliche Listen von Attributen und Angriffen können alle als Beschreibungsliste-Muster ausgedrückt werden
  • Um mehrere Beschreibungslisten voneinander zu unterscheiden oder mit einem Titel zu verknüpfen, können aria-label und aria-labelledby verwendet werden
  • Dieses Markup ist nur eine von mehreren Möglichkeiten und zeigt, wie allgemein einsetzbar das ``-Muster auch für unterschiedlich geformte Datensammlungen ist

2 Kommentare

 
GN⁺ 6 시간 전
Lobste.rs-Meinungen
  • Schade, dass es in Markdown keine Beschreibungsliste (description list) gibt
    • Pandoc-artiges Markdown unterstützt mindestens zwei Syntaxvarianten für Beschreibungslisten
      Allerdings werden sie von den meisten Implementierungen tatsächlich nicht unterstützt. Dagegen bietet das Satzsystem/Markup-Sprache Typst Beschreibungslisten mit einer erstklassigen Syntax wie / term: description, sodass sie sich meiner Meinung nach gut mit Aufzählungslisten mit - oder automatisch nummerierten Listen mit + kombinieren lassen
    • Einige Implementierungen wie Hugo, Pandoc und GFM unterstützen so eine Form meines Wissens
      dt  
      : dd  
      
      dt  
      : dd  
      
    • Markdown kann alles haben, was HTML hat, weil es eine Obermenge von HTML ist
    • https://www.djot.net/ unterstützt Beschreibungslisten. Noch wichtiger ist, dass Djot keine Obermenge von HTML ist und daher auch außerhalb von Browsern mit aufgeblähter HTML-Unterstützung verwendet werden kann
  • Für mich persönlich gehört das Element zu den Top fünf aller Zeiten
    • Zusammen mit <details> ist es definitiv ganz weit oben. Ich wünschte, es gäbe mehr solcher interaktiven Elemente
  • Man kann auch mehrere <dt> in einem Eintrag haben. Das lässt sich etwa verwenden, um Synonyme in einer Wörterbuchliste darzustellen
    Beim Styling mit CSS ist es sinnvoll, sich mit dem Adjacent-Sibling-Selektor vertraut zu machen
    Siehe: https://developer.mozilla.org/en-US/docs/…
 
GN⁺ 9 시간 전
Hacker-News-Meinungen
  • Das ist falsch: Für gibt es keine entsprechende implizite Rolle, aber man kann die Rollen `group`, `list`, `none` und `presentation` vergeben. `aria-label` kann nur für Elemente definiert werden, die eine kompatible Rolle haben, ob implizit oder explizit. `aria-label` ist bei den meisten Rollen erlaubt, aber hier fallen `presentation` und `none` weg, sodass nur `group` und `list` übrig bleiben. `group` ist ungeschickt, `list` ist akzeptabel, also lautet das Fazit: **Entweder `aria-label` weglassen** oder `role="list"` hinzufügen. Dann brauchen die Kindelemente auch `role="listitem"`. Übersehen wurde im Artikel, dass nicht nur ein einzelnes vorkommen kann, sondern mehrere hintereinander. Das Beispiel in der Spezifikation ist gut: https://html.spec.whatwg.org/multipage/grouping-content.html... Das ist kein Name-Wert-Paar, sondern eine Gruppe von Name-Wert-Paaren.

    • Das wusste ich überhaupt nicht. Interessant wäre: Würdest du dem -Element, das und umschließt, `role="listitem"` geben? `role="listitem"` scheint bei erlaubt zu sein, aber wenn mehrere zusammen gruppiert werden, wirkt das nicht ganz korrekt, und ich bin mir nicht sicher, ob dadurch auch die ursprüngliche Interpretation von als Begriff kaputtgeht.
    • Der alte Beitrag von HTML5 Doctor gefällt mir immer noch am besten: https://html5doctor.com/element-index/
  • Das ist hier vermutlich keine populäre Ansicht, aber seit ich nicht mehr krampfhaft versuche, semantisches HTML zu verwenden, ist mein Leben einfacher geworden. Das Design ist einfach nicht besonders gut. Jedes Mal, wenn ich versucht habe, zu verwenden, habe ich es am Ende bereut. Irgendwann brauchte ich mehrere Ebenen von Wrappern, Trennlinien zwischen Abschnitten, Icons oder Überschriften, die sich über mehrere Schlüssel-Wert-Paare erstrecken. Es gibt etwas Flexibilität, aber sie reicht bei weitem nicht aus, um das angeblich verallgemeinerte Konzept in der Praxis wirklich zu tragen. Natürlich nutze ich weiterhin passende Elemente wie oder ``, bei denen es einen beobachtbaren Vorteil gibt. Aber wenn es nicht wirklich zum Datenmodell passt und man ohnehin alles überschreiben muss, ist es keine praktische Wahl. Wenn in 99 % der Fälle die API umgangen wird, ist es vermutlich nicht besonders kontrovers zu sagen, dass das ein Fehler der API ist.

    • Als jemand, der täglich einen Screenreader benutzt, stimme ich vollkommen zu. Es wäre für alle besser, wenn das W3C aufhören würde, ideologischen Unsinn über semantische Reinheit zu erzählen, und stattdessen pragmatischer vorginge. Wichtiger als semantische Reinheit einer API ist, was Entwickler tatsächlich tun wollen, welche Tricks sie auch gegen Widerstand einsetzen werden und wie man das so ermöglicht, dass alle möglichst davon profitieren. ARIA live regions sind dafür ein perfektes Beispiel. Was Entwickler eigentlich wollen, ist document.speakText. Was sie tatsächlich haben, ist eine seltsame API, die Text auf der Seite vorliest, wenn er sich ändert. Diese Lücke muss überbrückt werden, und selbst bei guter Umsetzung ist das schwierig und wirkt fast wie ein Hack. Aber immerhin ist der Live-Region-Ansatz dann semantisch reines HTML.
    • Dann klingt das eher nach einem CSS-Problem. So wie display:contents Wrapper entfernen kann, sollte es auch eine Möglichkeit geben, Elemente so zu gruppieren, als hätten sie einen gemeinsamen Vorfahren. :wrap(dt, dt+dd) {border: solid 1px}
    • Ähnlich empfinde ich es bei HTTP. Für Ressourcenspeicher wie S3 passt das Protokoll wirklich gut. GET, PUT und DELETE ergeben alle Sinn, und die HTTP-Statuscodes sind genau für diesen Einsatzzweck gemacht. Aber als Webentwickler baut man meistens keine Ressourcenspeicher. Die sind extrem allgemein und sollten einmal gebaut werden, damit Millionen von Apps sie nutzen können. Wenn jemand Code schreibt, der mit HTTP interagiert, führt diese Person meistens Remote Procedure Calls aus. Mit GraphQL, gRPC oder anderen RPC-Systemen umgeht man das komplett. Alles geht als POST an einen einzigen Endpoint, und man zieht eine weitere Abstraktionsschicht ein, sodass man nicht für jeden sehr anwendungsspezifischen Fall 4XX-/5XX-Fehler zurückgeben muss. Die RFC-Autoren haben es da offenbar etwas übertrieben. 402 Payment Required, 407 Proxy Authentication Required, 508 Loop Detected wirken wie Versuche, Funktionen für bestimmte Anwendungen oder Deployment-Typen in das Fundament des Webs hineinzudrücken. Ich verstehe nicht, warum die konkreten Bedürfnisse der RFC-Autoren im Fundament des Webs umgesetzt werden, während ich für meine Bedürfnisse nur zufällige Überschneidungen suchen und alle anwendungsspezifischen Dinge in 400 Bad Request oder 500 Internal Server Error stopfen soll. Jedes Mal, wenn ich sehe, dass eine Web-App mehr als die absolut nötigsten HTTP-Statuscodes tatsächlich verwendet, rolle ich mit den Augen. Das gehört in die Anwendungsschicht. Dieses Protokoll wurde nicht für dich gebaut, sondern für LAMP-Stack-Apps, die größtenteils statische Assets auslieferten.
  • Eine kleine Geschichtsstunde zu Listen. Wenn man ins IBM-Mainframe-Handbuch DCF/GML von 1985 schaut, sieht man, dass DL-DT-DD schon vor dem Web existierte. In dem über 40 Jahre alten Dokument gibt es neben Definition lists (DL) auch Glossary lists (GL), Ordered lists (OL), Unordered lists (UL) und Simple lists (SL). ibm :: 370 :: DCF :: SH35-0050-2 Document Composition Facility Generalized Markup Language Implementation Guide Rel 3 Mar85 https://archive.org/details/bitsavers_ibm370DCFSpositionFaci...

    • GML geht auf 1969 zurück, SGML auf die 1970er. Intern wurde etwas namens BookMaster verwendet, das wie ein Vorläufer von HTML aussah. Statt `` schrieb man :p., statt `
  • schrieb man:li.`. Um 1990–1991, als TBL HTML und HTTP entwickelte, gab es auch den Versuch namens HyTime, eine auf Hypermedia fokussierte SGML-Anwendung. HTML hat das ziemlich schnell verdrängt. Zu Charles Goldfarb, der GML/SGML vorantrieb: https://en.wikipedia.org/wiki/Charles_Goldfarb, zu SGML: https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La...

    • Das IBM-Generalized Markup Language entwickelte sich zu SGML (Standard Generalized Markup Language), und soweit ich weiß, wurde SGML bei CERN, wo Tim Berners-Lee an HTML arbeitete, intensiv genutzt. HTML ist daraus stark abgeleitet. Das Interessante an HTML ist, dass irgendeine Form von Auszeichnungssprache jahrzehntelang herumexistierte und Berners-Lee dann Hyperlinks hinzufügte.
    • Heißt das heute nicht description list?
  • Die allererste Website der Welt verwendet häufig ``. https://info.cern.ch/hypertext/WWW/TheProject.html https://info.cern.ch/ ist eine Art Landingpage, die Kontext und Wegweiser zur eigentlichen ersten Website liefert.

  • Native GUI-Toolkits sind alle tot, und jetzt können Leute lange Essays über ein einziges HTML-Element schreiben. Ob das wirklich Fortschritt ist?

  • Vor HTML5 nannte man das eine definition list, und ich erfahre gerade erst, dass `` ursprünglich nur Glossare aus Begriffen und Definitionen darstellen sollte. Ich habe den Namen also zehn Jahre lang falsch verwendet.

    • Dass b jetzt für „bring attention to“ steht. Na wunderbar.
    • Du bist nicht allein. Diese Woche ist mir das zum zweiten Mal begegnet, und beim ersten Mal hielt ich es für einen Fehler.
    • Ich erfahre gerade erst, dass definition list umbenannt wurde.
    • Ich will lieber nicht nachschauen, in welchem Jahr HTML5 standardisiert wurde. Es ist wahrscheinlich schon mehr als zehn Jahre her ;)
  • Guter Artikel. Als ganz kleine Spitzfindigkeit: Das small-Element sollte nicht für Untertitel verwendet werden, dafür ist das hgroup-Element da. Das small-Element steht für ergänzende Kommentare wie Kleingedrucktes. In solchem Kleingedruckten stehen typischerweise Haftungsausschlüsse, Hinweise, rechtliche Einschränkungen oder Copyright-Hinweise. Gelegentlich wird es auch verwendet, um Quellenangaben oder Lizenzanforderungen zu erfüllen. (https://html.spec.whatwg.org/multipage/text-level-semantics....)

  • Es gibt eine nützliche Notiz dazu, wie gut Screenreader `` unterstützen: https://adrianroselli.com/2025/01/updated-brief-note-on-desc...

  • Beim letzten Beispiel mit dem DnD-Attributbogen habe ich mich gefragt, ob verschachtelte `` ebenfalls zulässig sind. Also zum Beispiel so etwas wie Actions ...?

  • Ich mag . Zumindest früher wurden Tabellen wohl noch häufiger missbraucht als , und die Umständlichkeit von Tabellen-Markup ist noch schlimmer als mehrere div.

    • Wenn man unnötige schließende Tags weglässt, ist es gar nicht so umständlich. first second what ever Ich finde das einfacher und sauberer als jede Markdown-Tabellensyntax.
    • Stimmt. Aber Tabellen dazu zu zwingen, `` nachzuahmen, war immer noch eine deutlich bessere Form des Tabellenmissbrauchs.
    • Ich habe `` immer wie eine einzelne Tabellenzeile betrachtet.