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

TablesNG se lance dans Chromium 91 et corrige un nombre important de bugs présents sur 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 amélioreront l'utilisation des tables sur la plate-forme Web dans son ensemble. Parmi les problèmes les plus signalés, citons l'position: sticky dans les lignes, la géométrie de sous-pixel et le refroidissement de la bordure approprié.

L'effort TablesNG

TablesNG est une initiative de plusieurs années menée par le développeur Chrome Aleks Totic, qui vise à repenser complètement l'architecture de l'affichage des tables sur le Web. Les tables génèrent des frictions spécifiques dans le développement Web, en partie en raison de leur historique.

Composantes d'un tableau

Les tableaux ont été ajoutés au code 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, mais l'usage moderne consiste généralement à afficher des données tabulaires. Toutefois, il existe de grandes différences de comportement des tables entre les navigateurs. La plupart d'entre elles sont dues au fait que la spécification des tables est incomplète et manque de détails. Les tables étaient également implémentées 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 était donc incohérente.

Capture d'écran du site Web de Space Jam
La mise en page innovante des tableaux qui constituait le site Web de Space Jam, par le biais de Shannon Draper

La nouvelle spécification, le niveau 3 du module de table CSS, a été écrite après la réimplémentation des tables par Edge en 2018. TablesNG est un effort de refonte de l'architecture qui vise non seulement à suivre cette nouvelle spécification, mais aussi à corriger de nombreuses incohérences dans les tables en cours de route. Voici quelques-uns des changements les plus visibles qui en découlent:

  • Activation du positionnement persistant dans les lignes pour les longues tables qui défilent
  • Correction de l'alignement avec la géométrie des sous-pixels et les bordures du tableau.
  • Amélioration du rendu des arrière-plans et des bordures.

position: sticky lignes

L'une des principales demandes et le plus frustrant de l'ajout de styles aux tables était le manque de prise en charge de position: sticky dans les lignes. Cette fonctionnalité permet à un en-tête de tableau de rester sur la page lorsque vous la faites défiler et fournit du contexte aux longues tables de données. Lorsque vous faites défiler l’en-tête hors de la vue et que vous consultez un tableau rempli de chiffres, il est facile d’oublier ce que ces chiffres signifient.

L'en-tête du tableau ne reste pas en position persistante, bien que position: sticky soit appliqué à <thead>.

Nous rencontrons ce bug 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 souhaité étaient simplement convertis en position: static. Vous pouvez désormais utiliser position: sticky n'importe où dans les tables: sur les en-têtes (<thead>) ou les libellés de l'axe vertical.

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

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

L'un des plus anciens bugs de table remonte à septembre 2008. Il a été enregistré presque dès la sortie de Chrome et n'a pas pu être corrigé en raison de l'ancienne architecture de table. Le problème concerne le tableau et les bordures réduits.

Les tableaux sont représentés par ordre de z-index: cellules > lignes > sections > tableaux. Elles sont ensuite affichées dans l'ordre dans lequel elles apparaissent dans le DOM (Document Object Model), même si les cellules elles-mêmes sont dans l'ordre DOM inverse, la première cellule du tableau étant la plus élevée.

Ordre z-index des tables

Le problème ici est que les bordures appartiennent au tableau, et non à la cellule, à l'ancienne façon dont les tableaux étaient peints. Les bordures réduites sont peintes lorsque le premier plan du tableau est peint. Cela signifie qu'une même cellule de tableau ne peut pas avoir plusieurs bordures:

rendu correct et incorrect du tableau
À gauche: rendu de table incorrect avant TablesNG. À droite: affichage correct des bordures d'un tableau dans TablesNG.

Dans l'exemple ci-dessus, vous pouvez constater que la cellule bleue la plus à gauche se peignait de manière incorrecte en haut de la cellule orange située en bas à droite, car elle ne pouvait pas avoir plusieurs bordures. Dans la nouvelle implémentation, ce problème est résolu et la cellule de bordure orange se superpose correctement à la cellule bleue, ce qui permet à la deuxième table d'avoir des bordures bleues et orange.

Ce bug est désormais corrigé dans Chromium et Firefox.

Géométrie des sous-pixels (alignement du tableau)

L'alignement des pixels dans les tables 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 se déplaçaient, ce qui causait des problèmes d'alignement. TablesNG résout ces problèmes d'alignement.

Modifier l'architecture du Web

L'équipe Chrome n'a pas seulement introduit de nouvelles fonctionnalités pour rendre la création Web plus robuste, 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 de l'architecture sur lesquels cette équipe a participé au cours des huit dernières années. D'autres, bien que pas tous, incluent:

  • LayoutNG: une réécriture complète de tous les algorithmes de mise en page, pour une fiabilité considérablement améliorée et des performances plus prévisibles.
  • BlinkNG: nettoyage et refactorisation systématique 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: un effort à long terme pour déployer la rastérisation GPU sur toutes les plates-formes, dans la mesure du possible.
  • Défilement et animations par thread: effort à long terme pour déplacer toutes les animations de défilement et qui n'influent pas sur la mise en page vers le thread compositeur.

Ne manquez pas les prochaines mises à jour de ces améliorations et plus encore !