Wussten Sie, dass es auch für HTML-Tabellen eine API gibt?

• Die HTMLTableElement API existiert schon lange, ist aber eine kaum genutzte eingebaute Schnittstelle zur Manipulation von HTML-Tabellen
• Mit dieser API lassen sich tbody, thead, tfoot, caption, row, cell usw. direkt erzeugen und ansprechen, ohne dass bei Änderungen die gesamte Tabelle neu gerendert werden muss
• Der Beispielcode zeigt, wie sich verschachtelte Array-Daten in eine Tabelle umwandeln lassen und wie man mit insertRow() und insertCell() Zeilen und Zellen hinzufügt
• Möglich sind auch verschiedene weitere Operationen, etwa der Zugriff auf Zellen per Index wie in t.rows[1].cells[1] oder das Anhängen der letzten Zeile mit insertRow(-1)
• Der Autor erwähnt, dass diese API Potenzial für eine erweiterte Tabellenfunktion als Datenstruktur hat und sich ähnlich wie bei Formularen durch Events oder Zusatzfunktionen ausbauen ließe

---

Überblick über die HTML-Tabellen-API

• Die meisten Entwickler erzeugen Tabellen mit DOM-Methoden (createElement usw.) oder durch das Einfügen von innerHTML-Strings, wobei Letzteres Sicherheitsrisiken birgt
• In HTML gibt es die ältere HTMLTableElement API, mit der sich Tabelleninhalt, Zeilen, Zellen, Kopfbereich, Fußbereich, Beschriftung und Zusammenfassung (summary) behandeln lassen
• Mit dieser API können einzelne Elemente manipuliert werden, ohne die gesamte Tabelle neu zu rendern

Codebeispiel: Eine Tabelle aus Arrays erzeugen

• Im Beispiel wird das folgende verschachtelte Array in eine Tabelle umgewandelt
  • [['one','two','three'], ['four','five','six']]
• Die Tabelle wird mit document.createElement('table') erstellt, danach werden per Schleife die einzelnen Zeilen (insertRow) und Zellen (insertCell) hinzugefügt
• Der Inhalt jeder Zelle wird über innerText gesetzt

Zugriff auf Zellen und Bearbeitung

• Auf die Zellen der erzeugten Tabelle kann indexbasiert zugegriffen werden
  • Beispiel: t.rows[1].cells[1] → <td>five</td>
• Zeilen und Zellen lassen sich auch löschen oder neu hinzufügen
  • Beispiel: Mit t.insertRow(-1) wird am Ende eine Zeile angefügt
  • Mit t.rows[2].insertCell(0) wird eine neue Zelle erzeugt und anschließend per innerText = 'foo' mit einem Wert belegt

Grenzen der API

• Es gibt nicht intuitive Indexregeln wie bei insertRow(-1)
• Es gibt keine direkte Möglichkeit, ein TH-Element zu erzeugen, alle Zellen werden als TD behandelt

Mögliche Erweiterungen in Zukunft

• Der Autor weist darauf hin, dass die Erstellung von Tabellen in der Praxis umständlich ist, und schlägt vor, diese API erneut zu betrachten und funktional zu erweitern
• So wie HTML-Formulare um formData oder change-Events ergänzt wurden, könnten auch Tabellen Events oder fortgeschrittene Funktionen erhalten
• Dadurch könnten Tabellen den Status einer Datenstruktur statt nur eines Layout-Werkzeugs bekommen

[sonnet]

Als Entwickler mit vergleichsweise wenig Erfahrung bin ich überrascht von Artikeln, die so wirken, als hätten sie APIs, die es schon von Anfang an gibt, erst jetzt „entdeckt“.

[GN⁺]

Hacker-News-Kommentare

• Viele Leute scheinen den Artikel nicht richtig gelesen zu haben Der Kern des Beitrags ist nicht das ``-Tag selbst, sondern die spezielle DOM-Schnittstelle für Tabellen Methoden wie HTMLTableElement.prototype.insertRow() oder HTMLTableRowElement.prototype.insertCell() sind zum Beispiel intuitiver als createElement() oder appendChild() In bibliotheksbasierten UIs wie React, Svelte oder Vue werden solche Methoden heute aber kaum noch verwendet Interessant ist, dass wie in der HTML-Syntax thead, tbody und tfoot auch dann automatisch verarbeitet werden, wenn man sie weglässt Ich habe in den letzten fünf Jahren in Demo-Skripten selbst direkt .insertRow, .insertCell, .createTHead, .rows und .cells verwendet Vom Code-Stil her finde ich for statt forEach sauberer, und auch das Weglassen des Index-Arguments wirkt auf mich aufgeräumter

  • Heutzutage ersetzen Frameworks grundlegende DOM-Manipulation so stark, dass nur noch wenige diese Basics wirklich kennen Das erinnert mich daran, wie ich damals den C|net-Artikel gelesen habe, als das ``-Tag neu eingeführt wurde. Ich bin wohl inzwischen auch ziemlich alt

• Ich erinnere mich, diese API vor etwa einem halben Jahr verwendet zu haben, nachdem ich die MDN-Dokumentation gelesen hatte oder sie mir von einer AI empfohlen wurde Die Eigenschaften rows und cells waren für die Implementierung der Tastaturnavigation sehr praktisch Ein passendes Beispiel findet sich im ClickHouse-Code

  • Was mich am heutigen Web am meisten frustriert, sind Leute, die Tabellen mit divs bauen Da funktioniert dann oft nicht einmal Sortierung richtig, und gerade bei M365 Admin gibt es viele Beispiele für miserabel umgesetzte Tabellen

• Das ist ein ähnlicher Kontext wie die Diskussion über Buttons (früherer Thread) Seit vor etwa 10 bis 15 Jahren alles zu `` geworden ist, wird HTML statt für semantisches Markup eher wie ein UI-Werkzeugkasten benutzt

  • Das liegt daran, dass das DOM ursprünglich nicht als semantisches Dokument, sondern als Rendering-Ziel verwendet wird Semantisches HTML ist ein gutes Konzept, aber in der Praxis nur schwer zu erwarten Außerdem haben semantische Elemente Standard-Styles, weshalb Entwickler eher das neutrale bevorzugen Eigentlich halte ich schon die Trennung zwischen und `` für einen Designfehler
  • Ich benutze HTML seit über 20 Jahren, und meiner Erfahrung nach verwenden die meisten immer noch aussagekräftige Tags sinnvoll Natürlich wickeln manche alles in divs, aber Dinge wie Buttons werden im Großen und Ganzen meist korrekt geschrieben
  • Ich halte diese Entwicklung für unvermeidlich Der Großteil der Inhalte im Web ist marketinggetrieben, und Unternehmen wollen, dass alles genau in der gewünschten Form erscheint Wenn es ein separates DocBook-Web für technische Dokumentation gäbe, in dem Nutzer selbst Styles anwenden könnten, wäre das interessant

• Ich habe diese API beim Bau eines Tools zum Vergleich von Stable-Diffusion-Bildern verwendet Weil es viele Zeilen und Spalten gab und die Tabelle oft neu erzeugt werden musste, waren DOM-Updates langsamer als die Methode, alles auf einmal als String zu erzeugen Vermutlich liegt das daran, dass jeder API-Aufruf das DOM sofort aktualisiert

• Es hieß, man müsse nicht "die ganze Tabelle neu rendern", aber tatsächlich verhalten sich die Standard-DOM-Methoden ohnehin schon so Trotzdem ist es ziemlich nett, dass sich langweiliges DOM-Durchhangeln reduzieren lässt

  • Ich habe mir den WebKit-Code angesehen, und intern läuft dieselbe Logik, daher gibt es praktisch keinen Performance-Unterschied

• Auch die HTML-Form-API sollte man wieder neu entdecken

• Das Problem bei Tabellen ist nicht das Befüllen mit Daten, sondern dass Suche, Sortierung und Filterung komplett fehlen

  • Ich frage mich, im Vergleich wozu das gesagt wird Ich sehe keinen Grund, warum man solche Funktionen nicht auch bei Tabellen umsetzen könnte

• Ich verstehe nicht, was mit "diese API wurde aufgegeben" gemeint ist Ich nutze sie beim Erstellen von HTML-Tabellen immer noch häufig

  • Der Ausdruck „Abandonware“ ist eigentlich ein Begriff aus dem Lizenzkontext, daher ist das hier als Titel etwas übertrieben Der Autor wollte wohl sagen, dass diese API ein alter Bereich mit Erweiterungspotenzial ist Wie bei der Form-API könnten auch Tabellen Funktionen wie Sortierung und Filterung bekommen
  • Heute verwenden die meisten deklarative UI-Frameworks wie React oder Svelte, deshalb werden solche imperativen DOM-APIs immer mehr zur Nische
  • Kurz gesagt: Wir leben heute im React-Zeitalter

• Der Beispielcode ist interessant, aber die Variablennamen sind zu stark verkürzt und dadurch schlechter lesbar Statt b, t, r, c sollte man besser aussagekräftige Namen verwenden

  • Solche Diskussionen wirken am Ende oft wie eine Fahrradschuppen-Debatte, also ein Fokus auf Nebensächlichkeiten
  • In einem kleinen Scope sind kurze Variablennamen durchaus natürlich
  • Trotzdem halte ich einbuchstabige Variablennamen für eine falsche Optimierung Gerade als jemand, der Haskell nutzt, kann ich das besonders gut nachvollziehen
  • Verwirrender als kurze Namen an sich ist die Mischung von Indexnamen wie (ri, i) Variablen mit ähnlicher Rolle sollten auch in ihrer Länge einheitlich sein
  • Zeilen wie let b = document.body; sind besonders schwer zu lesen Für ein paar gesparte Bytes steigt nur die kognitive Last