En action !
Passons immédiatement à la pratique, et procédons à quelques tests de routine.
Prenons au hasard deux éléments “block” classiques, disons deux <div>
, et modifions simplement la valeur de leur propriété intrinsèque display
(block) par la valeur table-cell
:
Avant (block
) :
div {display: table-cell;}
table-cell
) :
Les deux éléments s’affichent à présent l’un à côté de l’autre tels des éléments inline. Mais contrairement à un rendu inline, ces éléments table-cell peuvent être dimensionnés :
div {display: table-cell;}
div:first-child {width: 150px;}
Nous n’avons pas modifié la sémantique des éléments HTML, ce sont toujours des <div>
, nous n’avons fait que modifier leur rendu par défaut via CSS, comme nous l’aurions fait en passant de display: block
à display: inline
par exemple.
Algorithme de calcul des tableaux : table-layout
Contrairement à la croyance commune, ce n'est pas un mais un double algorithme qui définit le rendu des structures tabulaires :
-
Le modèle automatique (
table-layout: auto
) appliqué par défaut confère le pouvoir aux contenus des cellules. Ces derniers déterminent la largeur des colonnes : plus le contenu est dense, plus la colonne est large. Les largeurs width renseignées pour la table ou ses cellules ne seront qu’indicatives. -
Le modèle fixe (
table-layout: fixed
) se base sur la largeur réelle du tableau et de ses colonnes, et ne dépend pas du contenu.
Définir l’algorithme d’affichage en mode fixe a plusieurs avantages :
-
Dès qu’un élément de colonne a une valeur
width
, alors cette valeur est retenue pour la largeur de toute la colonne. Les éventuelles colonnes restantes se partagent équitablement l’espace horizontal restant de la table. - Le navigateur peut commencer à afficher la table dès la réception de la première rangée. De manière générale, cet algorithme accélère les traitements et l’affichage par le navigateur (pas de reflow inutile).
-
Les contenus n’affectent pas les largeurs des colonnes. Toute cellule s’appuie sur la propriété
overflow
pour déterminer le rognage, ou non, du contenu qui déborderait, ou encore des propriétés de césure telles queword-wrap
ouhyphens
. - Dans le cas de tableaux de données complexes, mon expérience m’a appris à apprivoiser ce mode de rendu plus strict et robuste que le rendu automatique… et qui est reconnu dès Internet Explorer 5 (et les autres navigateurs également, bien entendu).
Prenons pour exemple : un parent tabulaire contenant trois enfants en table-cell
. Les dimensions (width
) de chaque élément sont spécifiés en CSS : 600px pour le parent et 200px pour chacun des trois enfants :
En ajoutant une image de plus de 200 pixels de large au sein de la première cellule, celle-ci s'étire ainsi que tout l'ensemble du tableau. Le contenu est roi, c'est le comportement par défaut de table-layout: auto
:
En faisant bénéficier le parent d'un table-layout: fixed
, chaque élément conserve ses largeurs définies, et le contenu déborde comme dans n'importe quel autre élément HTML :
Commentaires
Bien présenté, bien écrit, super agréable à lire. Merci d'avoir rempli ma tête d'informations que j'ignorais totalement.
Merci Raphaël de mettre encore et toujours ses compétences au service des autres.
Je ne comprends pas l'utilité des pseudo-éléments? Dans quels cas peut-on y avoir recours.
Il y a mille et un usages possibles des pseudo-éléments, en voici un par exemple : codepen.io/raphaelgoetter/pen/dGxvL
Merci Raphaël.
Voilà au moins un usage, pour les mille autres, je garderai l'oeil ouvert.:)
Bon week-end.
Bonjour et merci pour cet article très instructif !!
J'ai une question sur un des points : les propriétés "display: table-header-group" par exemple - dont la position dans le flux semble puissante - peut elle être utilisée dans le cadre d'une chorégraphie de contenus telle qu'imaginée par Trent Walton ?
La compatibilité mobile de ces propriétés est excellente, et ce pourrait être une ingénieuse solution à certaines questions existentielles des intégrateurs en ce moment !
Merci pour la lecture en tout cas, les détails sont croustillants comme on aime !
... quid des webmails et outils tels que Thunderbird, Outlook, Mail (macOs) ? Faut-il garder nos vieux tableaux pour les newsletters ?
Pour ceux qui voudraient une version pdf (bricolée) de ce tuto, c'est par là : http://perso.jojaba.fr/Web-utilisation-develo... ;)
@Ten : en effet, de belles choses sont promises à ces valeurs de table qui modifient l'ordre d'affichage (en attendant flexbox bien plus poussé dans ce domaine). Mais attention à l'accessibilité de ces techniques !
@cynic- : les clients mails sont toujours aussi réfractaires aux styles CSS "évolués", il faut donc toujours se fier aux "vrais" tableaux HTML pour eux :(
Je ne suis pas expert en accessibilité mais je sens que ça va être mon nouveau seau dans le bac à sable, c'est l'occasion d'apprendre !!
Merci pour la réponse éclairée.