TablesNG résout 72 bugs Chromium pour une meilleure interopérabilité

TablesNG est lancé dans Chromium 91 et corrige une tonne de bugs qui sont intégrés à la plate-forme Web depuis des années. Ces mises à jour amélioreront la compatibilité des navigateurs dans le cadre de l'initiative #Compat2021 et l'utilisation des tableaux sur la plate-forme Web dans son ensemble. Voici quelques-uns des problèmes les plus marqués d'une étoile : position: sticky dans les lignes, géométrie sous-pixel et réduction des bordures.

L'effort TablesNG

TablesNG est un projet de plusieurs années, dirigé par le développeur Chrome Aleks Totic, qui vise à repenser complètement la façon dont les tableaux sont affichés sur le Web. Les tableaux sont un domaine particulier de friction dans le développement Web, en partie en raison de leur histoire.

Composantes d'un tableau

Les tableaux ont été ajoutés au langage HTML en 1994, puis utilisés comme méthode principale pour créer des mises en page complexes pendant de nombreuses années. On les trouve encore partout sur le Web, bien que l'utilisation moderne consiste généralement à afficher des données tabulaires. Toutefois, le comportement des tables varie considérablement d'un navigateur à l'autre, en raison de la spécification des tables incomplète et manquant de détails. Les tableaux ont également été implémentés dans les navigateurs avant de nombreuses fonctionnalités CSS : modes d'écriture orthogonaux, position:relative, box-sizing, conteneurs flexbox, etc. La prise en charge d'un grand nombre de ces fonctionnalités n'était donc pas la même.

Capture d'écran du site Web de Space Jam
Disposition innovante de la table du site Web de Space Jam, via Shannon Draper.

La nouvelle spécification, CSS Table Module Level 3, a été écrite après la réimplémentation des tableaux par Edge en 2018. TablesNG est un effort de refonte qui vise non seulement à suivre cette nouvelle spécification, mais aussi à corriger de nombreuses incohérences dans les tables au fil du temps. Voici quelques-unes des modifications les plus visibles qui en ont découlé:

  • Activation du positionnement persistant dans les lignes pour les tableaux longs à faire défiler.
  • Correction de l'alignement avec la géométrie au niveau des sous-pixels et les bordures de tableau.
  • Amélioration de la peinture pour les arrière-plans et les bordures.

position: sticky lignes

L'une des demandes les plus importantes et les plus frustrantes concernant le style des tableaux dans le passé était l'absence de prise en charge de position: sticky dans les lignes. Cette fonctionnalité permettrait à un en-tête de tableau de rester sur la page lorsque vous faites défiler la page et de donner du contexte aux tableaux de données longs. Lorsque vous faites défiler l'en-tête hors de la vue et que vous regardez un tableau rempli de chiffres, il est facile d'oublier ce que ces chiffres signifient.

L'en-tête de la table ne reste pas en position fixe, bien que position: sticky soit appliqué à <thead>.

Ce bug existe depuis si longtemps, car position: sticky a été spécifié bien après la sortie des tableaux HTML. Avant ce correctif, les en-têtes avec un position: sticky prévu étaient simplement convertis en position: static. Désormais, vous pouvez utiliser position: sticky n'importe où dans les tableaux: dans les en-têtes (<thead>) ou dans les libellés des axes verticaux.

L'en-tête du tableau présente un positionnement persistant dans Chromium 91 et versions ultérieures. Voir la démonstration sur Codepen

Amélioration de la peinture de la bordure et de l'arrière-plan

L'un des plus anciens bugs de table remonte à septembre 2008. Elle a été déposée presque dès le lancement de Chrome et n'a jamais pu être corrigée en raison de l'ancienne architecture des tables. Le problème concerne la peinture de tableau et les bordures réduites.

Les tableaux sont peints dans l'ordre suivant (par ordre de z-index) : cellules > lignes > sections > tableaux. Elles sont ensuite peintes dans l'ordre dans lequel elles apparaissent dans le DOM (Document Object Model), bien que les cellules elles-mêmes soient dans l'ordre DOM inverse, où la première cellule du tableau est la plus haute.

Ordre z-index des tables

Le problème est donc que les bordures appartiennent à la table, et non à la cellule, comme c'était le cas auparavant. Les bordures réduites sont peintes lorsque le tableau peint son premier plan. Cela signifie qu'une seule cellule de tableau ne peut pas avoir plusieurs bordures:

Affichage correct et incorrect d&#39;un tableau
À gauche: rendu incorrect de la table avant TablesNG. À droite: affichage correct des bordures d'un tableau dans TablesNG.

Dans l'exemple ci-dessus, vous pouvez voir que la cellule bleue la plus à gauche était mal peinte sur la cellule orange en bas à droite, car elle ne pouvait pas avoir plusieurs bordures. Dans la mise en œuvre remaniée, ce problème est résolu, et la cellule de bordure orange se superpose correctement à la cellule bleue, ce qui permet à l'espace vide de la deuxième table de comporter à la fois des lignes de bordure bleues et orange.

Ce bug est maintenant corrigé dans Chromium et Firefox.

Géométrie des sous-pixels (alignement des tableaux)

L'alignement des pixels dans les tableaux est un autre problème d'interopérabilité qui a été résolu avec TablesNG. Auparavant, l'ancien moteur arrondissait toujours les valeurs graphiques au pixel. Par conséquent, lorsque vous faites un zoom avant ou arrière sur la page, les choses changeaient, ce qui entraînait des problèmes d'alignement. TablesNG résout ces problèmes d'alignement.

Restructurer le Web

L'équipe Chrome a non seulement lancé de nouvelles fonctionnalités pour renforcer l'édition Web, mais elle a également travaillé dur pour améliorer les API existantes et leur compatibilité. En fait, TablesNG n'est qu'un des nombreux projets de refonte que cette équipe a entrepris au cours des huit dernières années. Voici d'autres projets, mais pas tous:

  • LayoutNG: réécriture complète de tous les algorithmes de mise en page, pour une fiabilité grandement améliorée et des performances plus prévisibles.
  • BlinkNG: nettoyage et refactorisation systématiques du moteur de rendu Blink en phases de pipeline clairement séparées. Cela permet une meilleure mise en cache, une plus grande fiabilité et des fonctionnalités de rendu réentrant/retardé, telles que content- visibility et les requêtes de conteneur.
  • GPU Raster Everywhere: effort à long terme visant à déployer la rastérisation GPU sur toutes les plates-formes, dans la mesure du possible.
  • Défilement et animations en threads: effort à long terme pour déplacer toutes les animations défilantes et non induisant une mise en page vers le thread du compositeur.

Nous vous tiendrons informé des prochaines nouveautés à venir.