Ce bon vieux tableau HTML

Hier, sur Twitter, j’ai conseillé d’utiliser des tableaux HTML pour de la mise en forme. Et je n’ai même pas honte.

En 2011 déjà, lors d’un atelier Paris-Web, je vantais les mérites des tableaux HTML pour de l’habillage graphique.

Au cours de cette présentation, je revenais point par point sur chacun des arguments anti-tableaux :

  • Non, un tableau n’est pas forcément lourd et complexe (rien ne vous impose de les imbriquer),
  • Non, un tableau n’est pas forcément inaccessible (un tableau peut être linéarisé, et il existe de nombreux attributs HTML et ARIA pour rendre un tableau accessible),
  • Non, les tailles des cellules d’un tableau ne sont pas forcément incontrôlables car dépendantes de leur contenu (il existe table-layout: fixed – du CSS1 – pour maîtriser les dimensions des tableaux),
  • Non, le rendu d’un tableau n’est pas forcément lent pour le navigateur (table-layout fait un boulot formidable pour la performance),
  • Oui un tableaux peut être rendu responsive (tout simplement en rendant les cellules en display: block par exemple),
  • Oui, un tableau n’est pas vraiment sémantique (mais les attributs role d’ARIA changent grandement la donne),
  • Oui, le code d’un tableau est souvent superflu pour réaliser des choses simples (nécessité de table, tr, td),
  • Oui utiliser des tableaux de mise en page est obsolète (mais tout autant que d’utiliser des float pour le même résultat).

Bref, l’idée globale de ma présentation était à cette époque de revenir sur le classique « les tableaux HTML, c’est le Mal absolu », tellement ancré dans nos esprits que l’on ne se pose même plus de questions.

En 2015, avec toutes les techniques de positionnement actuels (inline-block, table-cell, flexbox, etc.), et avec tout le mal qu’on a pu dire des tableaux HTML, comment est-il encore possible que j’en parvienne à conseiller son usage ?

Tout simplement parce que l’on m’a demandé comment réaliser ce type de gabarit, a priori très simple :

joli gabarit

Aussi évident que puisse paraître ce gabarit, il est extrêmement complexe à concevoir avec des float, des position: absolute, des inline-block, des table-cell et même avec Flexbox (ce dernier nécessiterait une hauteur globale fixe, ce qui n’est pas souhaité). En tout cas sauf grosses bidouilles ou de conteneurs supplémentaires.
Seul Grid Layout apporte une solution parfaite, mais manque encore de compatibilité.

Selon moi, le meilleur choix, aujourd’hui, est le tableau HTML.

Ce tableau, nous pouvons le rendre à la fois accessible et « sémantique » grâce à l’apport des rôles « landmarks » ARIA.

<table role="presentation">
<!-- surtout pas d'attribut summary -->
  <tr>
    <td rowspan="2" class="aside" role="complementary" >aside</td>
    <td class="nav" role="navigation">navigation</td>
  </tr>
  <tr>
    <td class="main" role="main">main</td>
  </tr>
</table>

Le résultat en ligne : http://codepen.io/raphaelgoetter/pen/XmxNpW?editors=110

Si des spécialistes en CSS ou en Accessibilité ont envie d’intervenir pour améliorer le code ou trouver une autre solution, je prends !

15 réflexions au sujet de « Ce bon vieux tableau HTML »

    1. Certes, mais cette solution nécessite de rajouter un conteneur autour de nav et main, ce qui change la donne car le but serait de réaliser l’objectif sans conteneur superflu.
      … Mais en même temps, avec un tableau HTML on n’est également obligé d’ajouter des conteneurs.

    1. J’avoue que je n’ai pas trop compris :/ Si l’on souhaite que aside ait une largeur différente, il suffit de lui fixer une width par exemple.

  1. Proposition : http://codepen.io/meduzen/pen/yYRKge?editors=110

    Il manque des contraintes à ton énoncé (comportement et contenu des blocs internes, par exemple) pour proposer quelque chose de plus précis et pertinent.

    Sinon, les tableaux, c’est bien, à condition de les employer pour leur raison d’être : structurer des données. Dès lors qu’un attribut rowspan arrive dans le tableau-layout, ça veut dire qu’on ne peut entièrement se reposer sur le CSS pour la mise en forme. Si pour une raison ou pour une autre, tu fais passer ta structure sur 3 colonnes, et que le

    <

    aside> doit se retrouver au milieu, ça devient compliqué.

    1. En fait, ta proposition n’est pas viable en pratique : dès que tu fixes des hauteurs à toutes les boîtes, il y aura un problème avec du vrai contenu (ils vont forcément déborder ou casser les hauteurs prédéfinies).
      Sinon, ce que tu dis est vrai : dès lors qu’on doit changer la structure, ça devient compliqué, quelle que soit la solution choisie… sauf Grid Layout 😉

  2. Pour respecter le RGAA en théorie faudrait des vrais éléments NAV et MAIN. Les rôles aria ne sont préconisés que pour sécuriser la sémantique. AMHA ça giclera à l’avenir (déconseillés dans HTML5.1).
    A la rigueur tu pourras invoquer le fait que c’est la seule solution viable, dans un contexte de conformité. Mais du coup ce serait une dérogation.
    Sinon pour l’optimisation j’aurais pas mis des classes mais utilisé l’attribut role dans les sélecteurs CSS.

    1. Merci Olivier pour ces infos. Bon, au pire rien n’empêcherait de placer des NAV et des MAIN dans chacun des TD s’il le fallait vraiment.

      Pour ce qui est du choix des sélecteurs CSS, je préfère autant me détacher complètement de toute notion de structure et utiliser préférentiellement des classes, faites pour être ciblées en CSS, plutôt que d’autres attributs dont la fonction n’est pas vraiment faite pour être une cible CSS.

      Par contre je n’ai pas compris ce qui giclerait en HTML5.1 : les rôles landmarks ou la nécessité d’utiliser des « vrais » NAV et MAIN ?

  3. Bonjour,

    @Olivier, je serais moins catégorique : les landmarks role garderons un intérêt, au moins pour banner et contentinfo qui permettront d’indiquer les zones réelles d’en-têtes et de pied de page, ces éléments pouvant être présents plusieurs fois dans la page. Pour main et navigation la situation n’est pas nécessairement plus évidente du fait du désaccord entre le WATWG et le W3C au sujet de main et de l’utilisation anarchique de nav.
    En revanche les surcharges de role de type article role= »article » sont naturellement inutiles et pas réclamées par le RGAA.

    @Raphael : il y a une erreur dans le code que tu propose : l’utilisation du rôle « presentation » a pour conséquence d’inhiber la sémantique de table mais également de tous les éléments requis, à savoir tr et td. Du coup les landmark role sont implémentés sur rien. Ils restent néanmoins fonctionnels mais ils gagneraient fortement à être implémentés sur des wrappers dans les td via des éléments adh’oc comme le suggère Olivier.

    1. Merci pour ce complément très intéressant. Du coup, ça change effectivement la donne et complexifie encore un peu la structure :/

  4. De mon coté juste régulièrement le display table pour faire des alignements verticaux ou pour faire du liquide layout, mais je ne l’utilise qu’en CSS. Du coup pas besoin d’attributs supplémentaires, que de la présentation 😉
    Mais c’est vrai que ça nécessite parfois quelques éléments supplémentaires

Les commentaires sont fermés.