• 11 min de lecture
• CSS,JavaScript,Design Patterns,Responsive Web Design
• Enregistré pour une lecture hors ligne
• Partager sur Twitter, LinkedIn

Les tableaux sont un modèle de conception pour afficher de grandes quantités de données en lignes et en colonnes, ce qui les rend efficaces pour faire des analyses comparatives sur des objets catégoriels. Les tableaux ont été utilisés à cette fin dès le 2e siècle et lorsque le monde a commencé à devenir numérique, les tableaux sont venus avec nous.

Il était inévitable que le web prenne en charge l’affichage des données dans un format tabulaire. Les tableaux HTML présentent les données tabulaires d’une manière sémantique et structurellement appropriée. Cependant, les styles par défaut des tableaux HTML ne sont pas exactement la chose la plus esthétique que vous ayez jamais vue. En fonction de la conception visuelle souhaitée, un certain effort est nécessaire sur le front CSS pour embellir ces tableaux. Il y a dix ans, un article avec le “Top 10 CSS Table Designs” a été publié sur Smashing Magazine, et il continue de recevoir beaucoup de trafic à ce jour.

Le web a beaucoup évolué au cours de la dernière décennie, et il est plus pratique que jamais de faire en sorte que votre site ou votre application s’adapte au viewport dans lequel il est visualisé. Cela dit, nous devons continuer à faire des choix de conception réfléchis qui ne compromettent pas l’accessibilité. Puisque les tableaux ne semblent pas tomber en disgrâce de sitôt, voyons comment les tableaux peuvent être créés sur le web en 2019.

Options sans JavaScript

Si votre ensemble de données n’est pas si grand, et que des fonctionnalités comme la pagination et le tri ne sont pas nécessaires, alors envisagez une option sans JavaScript. Vous pouvez obtenir d’assez bons résultats qui fonctionnent bien sur toute une gamme de tailles d’écran sans le poids supplémentaire d’une grande bibliothèque.

Malheureusement, sans l’aide de JavaScript pour certaines manipulations DOM sur le front de l’accessibilité, nous n’avons qu’une poignée d’options uniquement CSS. Mais pour les petits ensembles de données, elles sont souvent suffisantes.

Option 1 : ne rien faire

Nous allons commencer par un scénario à faible effort. Si vos données tiennent dans un tableau avec seulement quelques colonnes et beaucoup de lignes, alors un tel tableau est à peu près prêt pour le mobile dès le départ.

Le problème que vous auriez est probablement d’avoir trop de place sur des écrans plus larges, il pourrait donc être conseillé de “plafonner” la largeur maximale du tableau avec un max-width tout en le laissant rétrécir si nécessaire sur un écran étroit.

Ce genre de modèle fonctionne mieux si vos données elles-mêmes ne sont pas des lignes et des lignes de texte. Si elles sont numériques, ou de courtes phrases, vous pouvez probablement vous en sortir sans faire grand-chose.

Option 2 : Style The Scroll

David Bushell a écrit sa technique pour les tableaux réactifs en 2012, qui impliquait d’invoquer le débordement et de permettre aux utilisateurs de faire défiler pour voir plus de données. On pourrait argumenter que ce n’est pas exactement une solution responsive, mais techniquement, le conteneur répond à la largeur du viewport.

Regardons d’abord le débordement “de base”. Imaginez que j’utilise des air-quotes autour de basic, parce que le stylisme des ombres défilantes est tout sauf cela. Toujours est-il que dans ce cas, “basic” fait référence au fait que le tableau ne se transforme en aucune façon.

Cette technique pour faire des ombres défilantes vient de Roma Komarov et Lea Verou qui renvoient leurs idées respectives pour créer de la magie. Elle s’articule autour de l’utilisation de plusieurs dégradés (linéaires et radiaux) comme images d’arrière-plan sur l’élément contenant, et de l’utilisation de background-attachment: local pour positionner l’arrière-plan par rapport à son contenu.

Ce qui est bien avec cette technique, c’est que pour les navigateurs qui ne prennent pas en charge les ombres de défilement, vous pouvez toujours faire défiler la table normalement. Cela ne casse pas du tout la mise en page.

Une autre option de défilement serait de retourner les en-têtes du tableau d’une configuration en ligne à une configuration en colonne, tout en appliquant un défilement horizontal sur le contenu de l’élément <tbody>. Cette technique tire parti du comportement Flexbox pour transformer les lignes du tableau en colonnes.

En appliquant display: flex à la table, cela fait des <thead> et <tbody> tous les deux des enfants flex, qui sont par défaut disposés les uns à côté des autres sur la même ligne flex.

Nous faisons également de l’élément <tbody> un conteneur flex, faisant ainsi de tous les éléments <tr> à l’intérieur de celui-ci des enfants flex disposés sur une seule ligne flex également. Enfin, chaque cellule de tableau doit avoir son affichage défini sur block au lieu du table-cell par défaut.

L’avantage de cette technique est que les en-têtes sont toujours en vue, comme un effet d’en-tête fixe, de sorte que les utilisateurs ne perdent pas le contexte lorsqu’ils font défiler les colonnes de données. Une chose à noter est que cette technique entraîne un décalage de l’ordre visuel et de l’ordre source, ce qui rend les choses légèrement peu intuitives.

Sprinkle On Some JavaScript

Comme mentionné précédemment, les options de mise en page qui impliquent le morphing du tableau en modifiant les valeurs display ont parfois des implications négatives pour l’accessibilité, ce qui nécessite quelques manipulations mineures du DOM pour rectifier.

En outre, il y a un certain nombre de conseils d’expérience utilisateur quand il s’agit de concevoir des tableaux de données d’Andrew Coyle, y compris des fonctionnalités comme la pagination, le tri, le filtrage, et ainsi de suite (fonctionnalités qui nécessitent un peu de JavaScript pour être activées).

Si vous travaillez avec un ensemble de données relativement plus simple, peut-être voudrez-vous écrire vos propres fonctions pour certaines de ces fonctionnalités.

Rows To Blocks, With Accessibility Fix

A ma connaissance, cette technique de tableau de données responsive est née de l’article de CSS-Tricks “Responsive Data Tables” par Chris Coyier en 2011. Elle a depuis été adaptée et développée par de nombreuses autres personnes.

L’essentiel de cette technique consiste à faire usage d’une requête média pour basculer la propriété d’affichage de l’élément table et de ses enfants sur block sur un viewport étroit.

Sur un écran étroit, les en-têtes du tableau sont visuellement cachés, mais existent toujours dans l’arbre d’accessibilité. En appliquant des attributs de données aux cellules du tableau, nous pouvons ensuite afficher des étiquettes pour les données via CSS, tout en conservant le contenu de l’étiquette dans le HTML. Veuillez vous référer au CodePen ci-dessous pour voir à quoi ressemblent le balisage et les styles :

La méthode originale applique une largeur sur le pseudo-élément affichant le texte de l’étiquette, mais cela signifie que vous auriez besoin de connaître la quantité d’espace dont votre étiquette a besoin pour commencer. L’exemple ci-dessus utilise une approche légèrement différente, dans laquelle l’étiquette et les données sont chacune sur les côtés opposés de leur bloc contenant.

Nous pouvons obtenir un tel effet via les marges automatiques dans un contexte de formatage flexible. Si nous définissons la propriété d’affichage pour chaque élément <td> à flex, parce que les pseudo-éléments génèrent des boîtes comme s’ils étaient des enfants immédiats de leur élément d’origine, ils deviennent des enfants flex des <td>.

Après cela, il s’agit de définir margin-right: auto sur le pseudo-élément pour pousser le contenu de la cellule vers le bord d’extrémité de la cellule.

Une autre approche faisant la mise en page du viewport étroit est d’utiliser une combinaison de Grid et display: contents. Veuillez noter que display: contents dans les navigateurs de soutien a des problèmes avec l’accessibilité en ce moment, et cette méthode ne devrait pas être utilisée en production jusqu’à ce que ces bugs soient corrigés.

Mais peut-être que vous lisez ceci après que ces bugs ont été résolus, dans ce cas, voici une option de mise en page alternative.

Chaque élément <tr> est réglé sur display: grid, et chaque élément <td> est réglé sur display: contents. Seuls les enfants immédiats d’un conteneur de grille participent à un contexte de formatage de grille ; dans ce cas, il s’agit de l’élément <td>.

Lorsque display: contents est appliqué à l’élément <td>, il est “remplacé” par son contenu, dans ce cas, le pseudo-élément et le <span> à l’intérieur du <td> deviennent les enfants de la grille à la place.

Ce que j’aime dans cette approche, c’est la possibilité d’utiliser max-content pour dimensionner la colonne de pseudo-éléments, assurant que la colonne sera toujours de la largeur de l’étiquette la plus longue, sans que nous ayons à lui attribuer manuellement une valeur de largeur.

À l’avenir, lorsque les valeurs de dimensionnement de min-content, max-content et fit-content (couvertes par le module CSS Intrinsic & Extrinsic Sizing Level 3) seront prises en charge en tant que valeurs générales width et height, nous aurons encore plus d’options pour disposer les choses.

L’inconvénient de cette approche est que vous avez effectivement besoin de cette <span> ou <p> supplémentaire autour du contenu de votre cellule de table si elle n’en avait pas déjà une, sinon, il n’y aurait aucun moyen de lui appliquer des styles.

Pagination simple

Cet exemple montre une implémentation de pagination de base qui a été modifiée hors de ce CodePen par Gjore Milevski pour paginer sur les lignes de la table au lieu des divs. Il s’agit d’une extension de l’exemple “style the scroll” discuté dans la section précédente.

Du point de vue de la mise en page, Flexbox s’avère très pratique pour positionner les éléments de pagination à travers différentes tailles de viewport. Les différentes conceptions de projet auront des exigences différentes, mais la polyvalence de Flexbox devrait vous permettre de répondre à ces différences en conséquence.

Dans ce cas, la pagination est centrée sur la page et au-dessus du tableau. Les contrôles pour naviguer en arrière et en avant sont placés de part et d’autre des indicateurs de page sur les écrans plus larges, mais les quatre apparaissent au-dessus des indicateurs de page sur les écrans étroits.

Nous pouvons faire cela en levant la propriété order. Le réordonnancement visuel du contenu devrait toujours être fait avec considération parce que cette propriété ne change pas l’ordre de la source – seulement la façon dont il apparaît sur les écrans.

Tri simple

Cet exemple montre une implémentation de tri de base modifiée à partir de cet extrait de code par Peter Noble pour prendre en charge à la fois le texte et les chiffres:

Il serait utile d’avoir une sorte d’indicateur de la colonne qui est actuellement triée et dans quel ordre. Nous pouvons le faire avec l’ajout de classes CSS qui peuvent ensuite être stylisées comme vous le souhaitez. Dans ce cas, les symboles indicateurs sont des pseudo-éléments qui sont basculés lorsque l’en-tête cible est cliqué.

Recherche simple

Cet exemple est une fonctionnalité de filtrage de base qui itère à travers tout le contenu textuel de chaque cellule du tableau et applique une classe CSS pour masquer toutes les lignes qui ne correspondent pas au champ de saisie de la recherche.

Une telle implémentation est relativement naïve, et si votre cas d’utilisation l’exige, il pourrait être judicieux de rechercher par colonne à la place. Dans ce scénario, ce pourrait être une bonne idée d’avoir chaque champ de saisie comme partie du tableau dans leurs colonnes respectives.

Let A Library Handle It

Les extraits JavaScript ci-dessus servent à démontrer comment les tableaux avec de plus grandes quantités de données peuvent être améliorés pour faciliter la vie des utilisateurs de ces tableaux. Mais avec de très grands ensembles de données, il serait probablement plus judicieux d’utiliser une bibliothèque existante pour gérer vos grands tableaux.

Le modèle de basculement de colonne est un modèle par lequel les colonnes non essentielles sont cachées sur les petits écrans. Normalement, je ne suis pas un fan de cacher le contenu simplement parce que le viewport est étroit, mais cette approche de Maggie Costello Wachs de Filament Group résout ce qualm de la mienne en fournissant un menu déroulant qui permet aux utilisateurs de basculer les colonnes cachées à nouveau en vue.

L’article ci-dessus a été publié en 2011, mais Filament Group a depuis développé une suite complète de plugins de tableaux réactifs connus sous le nom de Tablesaw, qui comprend des fonctionnalités telles que le tri, la sélection des lignes, l’internationalisation et ainsi de suite.

La fonctionnalité de basculement des colonnes dans TableSaw ne dépend également plus de jQuery, contrairement aux exemples de l’article original. Tablesaw est l’une des seules bibliothèques que j’ai pu trouver qui n’a pas de dépendance à jQuery pour le moment.

Wrapping Up

Il existe une myriade de modèles de conception de tableaux, et l’approche que vous choisissez dépend fortement du type de données que vous avez et du public cible de ces données. En fin de compte, les tableaux sont une méthode d’organisation et de présentation des données. Il est important de déterminer quelles informations comptent le plus pour vos utilisateurs et de choisir l’approche qui répond le mieux à leurs besoins.

Lectures complémentaires

• “Tables responsives uniquement en CSS”, David Bushell
• “Tables accessibles, simples et responsives”, Davide Rizzo, CSS-Tricks
• “Mise en page des tables responsives”, Matt Smith
• “Patrons responsives : Tables”, Brad Frost
• “Hé, c’est toujours bon d’utiliser des tables”, Adrian Roselli
• “Tables, propriétés d’affichage CSS et ARIA”, Adrian Roselli
• “Tables de données”, Heydon Pickering

(ra, il)

.