Saviez-vous qu’il existe aussi une API pour les tableaux HTML ?

• L’API HTMLTableElement existe depuis longtemps, mais c’est une interface intégrée de manipulation des tableaux HTML rarement utilisée
• Cette API permet de créer et d’accéder directement à tbody, thead, tfoot, caption, row, cell, etc., sans avoir à réafficher l’ensemble du tableau à chaque modification
• Le code d’exemple montre comment convertir des données en tableaux imbriqués en tableau HTML et ajouter des lignes et des cellules via insertRow() et insertCell()
• Il est possible d’accéder à une cellule par index comme avec t.rows[1].cells[1], ou d’effectuer diverses manipulations comme ajouter une dernière ligne avec insertRow(-1)
• L’auteur indique que cette API offre un potentiel d’extension des fonctionnalités du tableau en tant que structure de données, avec la possibilité d’y ajouter des événements ou d’autres fonctions, à l’image des formulaires

---

Vue d’ensemble de l’API des tableaux HTML

• La plupart des développeurs créent les tableaux avec des méthodes DOM (createElement, etc.) ou par insertion de chaînes innerHTML, mais cette dernière approche comporte des risques de sécurité
• HTML dispose d’une ancienne API HTMLTableElement, qui permet de manipuler le corps, les lignes, les cellules, l’en-tête, le pied, la légende, le résumé (summary), etc. d’un tableau
• Cette API permet de manipuler des éléments individuellement sans réafficher l’ensemble du tableau

Exemple de code : créer un tableau à partir d’un tableau

• L’exemple convertit le tableau imbriqué suivant en tableau HTML
  • [['one','two','three'], ['four','five','six']]
• Le tableau est créé avec document.createElement('table'), puis chaque ligne (insertRow) et cellule (insertCell) est ajoutée dans une boucle
• Le contenu de chaque cellule est défini avec innerText

Accès et modification des cellules

• Les cellules du tableau créé sont accessibles par index
  • Exemple : t.rows[1].cells[1] → <td>five</td>
• Il est aussi possible de supprimer ou d’ajouter des lignes et des cellules
  • Exemple : t.insertRow(-1) ajoute une ligne à la fin
  • t.rows[2].insertCell(0) crée une nouvelle cellule, puis innerText = 'foo' en définit la valeur

Limites de l’API

• Il existe des règles d’indexation peu intuitives, comme insertRow(-1)
• Aucun moyen n’est prévu pour créer directement un élément TH, toutes les cellules étant traitées comme des TD

Possibilités d’évolution

• L’auteur souligne le caractère fastidieux de la création de tableaux et propose de réexaminer cette API pour en étendre les fonctionnalités
• Comme des événements change ou formData ont été ajoutés aux formulaires HTML, il évoque la possibilité d’introduire dans les tableaux des événements ou des fonctions avancées
• Cela permettrait au tableau d’être considéré non plus comme un simple outil de mise en page, mais comme une véritable structure de données

[sonnet]

En tant que développeur relativement peu expérimenté, je suis surpris de voir des textes qui parlent avec émerveillement d’une API utilisée depuis le début, comme s’ils l’avaient « découverte ».

[GN⁺]

Avis Hacker News

• Beaucoup de gens semblent ne pas avoir lu l’article correctement Le point central ici n’est pas la balise `` elle-même, mais l’interface DOM dédiée aux tables Par exemple, des méthodes comme HTMLTableElement.prototype.insertRow() ou HTMLTableRowElement.prototype.insertCell() sont plus intuitives que createElement() ou appendChild() Mais dans les UI basées sur des bibliothèques comme React, Svelte ou Vue, on n’utilise presque plus ce genre de méthodes Il est intéressant de voir que, comme dans la syntaxe HTML, thead, tbody et tfoot sont gérés automatiquement même si on les omet Au cours des cinq dernières années, j’ai déjà utilisé directement .insertRow, .insertCell, .createTHead, .rows et .cells dans des scripts de démo Côté style de code, je trouve plus propre d’utiliser for plutôt que forEach, et d’omettre l’argument d’index

  • Aujourd’hui, les frameworks ont tellement remplacé les manipulations DOM de base qu’on a l’impression que peu de gens connaissent encore ces fondamentaux Ça me rappelle l’époque où je lisais l’article de C|net annonçant l’arrivée de la balise ``. J’imagine que je suis devenu assez vieux moi aussi

• Je me souviens avoir utilisé cette API il y a environ six mois, après l’avoir vue dans la documentation MDN ou sur recommandation d’une IA Les propriétés rows et cells étaient très pratiques pour implémenter la navigation au clavier On peut voir un exemple lié dans le code de ClickHouse

  • Ce qui me désole le plus sur le web actuel, ce sont les gens qui fabriquent des tableaux avec des div On ne peut même pas les trier, et il y a surtout beaucoup d’implémentations catastrophiques, comme dans M365 Admin

• C’est dans la même veine que la discussion sur les boutons (fil précédent) Depuis 10 à 15 ans, tout est passé en ``, et le HTML est utilisé comme une boîte à outils UI plutôt que pour du balisage sémantique

  • C’est parce que le DOM sert avant tout de cible de rendu, et non de document sémantique à l’origine Le HTML sémantique est une bonne idée, mais en pratique il est difficile d’en attendre grand-chose En plus, les éléments sémantiques ont des styles par défaut, ce qui pousse les développeurs à préférer le neutre En fait, je pense même qu’avoir séparé et `` était une erreur de conception
  • J’utilise HTML depuis plus de 20 ans, et d’après mon expérience, la plupart des gens utilisent encore correctement des balises porteuses de sens Bien sûr, certains mettent des div partout, mais pour les boutons par exemple, c’est généralement fait correctement
  • Je pense que cette évolution était inévitable La majorité du contenu du web est centré sur le marketing, donc les entreprises veulent qu’il apparaisse exactement comme elles le souhaitent S’il existait un web DocBook séparé pour la documentation technique, où les utilisateurs pourraient appliquer eux-mêmes le style, ce serait intéressant

• J’ai utilisé cette API en créant un outil de comparaison d’images Stable Diffusion Comme il y avait beaucoup de lignes et de colonnes, il fallait souvent recréer le tableau, mais les mises à jour du DOM étaient plus lentes qu’une génération en une seule fois sous forme de chaîne C’est probablement parce que chaque appel d’API met à jour le DOM immédiatement

• Il était expliqué qu’on pouvait « éviter de rerendre tout le tableau », mais en réalité les méthodes DOM standard fonctionnent déjà ainsi Cela dit, c’est plutôt sympa que ça permette de réduire les parcours DOM fastidieux

  • En regardant le code de WebKit, on voit qu’en interne c’est la même logique, donc il n’y a presque aucune différence de performances

• L’API des formulaires HTML mériterait aussi d’être redécouverte

• Le problème des tableaux, ce n’est pas de remplir les données, c’est l’absence totale de recherche, tri et filtrage

  • Je me demande par rapport à quoi tu dis ça Je ne vois aucune raison pour laquelle on ne pourrait pas implémenter ces fonctions avec des tableaux aussi

• Je ne comprends pas l’idée que « cette API a été abandonnée » Je l’utilise encore souvent quand je crée des tableaux HTML

  • Le terme « abandonware » s’emploie à l’origine dans un contexte de licence, donc ici le titre est un peu exagéré L’auteur voulait sans doute dire que cette API est un vieux domaine qui a encore du potentiel d’extension Comme pour l’API des formulaires, on pourrait imaginer ajouter aux tableaux des fonctions comme le tri ou le filtrage
  • Aujourd’hui, la plupart des gens utilisent des frameworks UI déclaratifs comme React ou Svelte, donc ce genre d’API DOM impérative devient de plus en plus une niche
  • En un mot, c’est l’ère de React aujourd’hui

• Le code d’exemple est intéressant, mais les noms de variables sont tellement abrégés que ça nuit à la lisibilité Il vaudrait mieux utiliser des noms explicites plutôt que b, t, r, c

  • Ce genre de discussion donne finalement l’impression de se concentrer sur des détails mineurs, comme dans un débat de type bikeshedding
  • Dans une portée courte, il est naturel d’utiliser des noms de variables courts
  • Malgré tout, je pense que les noms de variables d’une seule lettre sont une mauvaise optimisation En tant qu’utilisateur de Haskell, je compatis particulièrement avec ce point de vue
  • Plus que les noms courts eux-mêmes, c’est le mélange d’index comme (ri, i) qui prête à confusion Quand des variables jouent des rôles similaires, il vaut mieux harmoniser aussi leur longueur
  • Une ligne comme let b = document.body; est particulièrement difficile à lire Pour économiser quelques octets, on ne fait qu’augmenter la charge cognitive