Pourquoi les gens font des tables avec des divs?

Dans le développement web moderne, je rencontre de plus en plus souvent ce modèle. Cela ressemble à ceci:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

Et en CSS, il y a quelque chose comme:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

^{* (Les noms de classe sont uniquement illustratifs; dans la vie réelle, ce sont des noms de classe normaux reflétant le contenu de l'élément)}

J'ai même récemment essayé de le faire moi-même parce que ... vous savez, tout le monde le fait.

Mais je ne comprends toujours pas. Pourquoi fait-on ça? Si vous avez besoin d’une table, faites-en simplement une explosion <table>et finissez -en. Oui, même si c'est pour la mise en page. C’est à quoi servent les tables: disposer les éléments sous forme de tableau.

La meilleure explication que j'ai est que maintenant tout le monde a entendu le mantra de "n'utilisez pas de tableaux pour la mise en page", donc ils le suivent aveuglément. Mais ils ont toujours besoin d' un tableau pour la mise en page (car rien d'autre ne possède les capacités étendues d'un tableau), ils créent donc un <div>(car ce n'est pas un tableau!), Puis ajoutent du CSS qui en fait un tableau.

Pour le monde entier, cela me semble mettre sur votre chemin des obstacles inutiles et arbitraires, puis un travail supplémentaire pour les contourner.

L'argument initial pour s'éloigner des tableaux pour la présentation était qu'il était difficile de modifier une disposition tabulaire par la suite. Mais modifier une mise en page "faux-table" est tout aussi difficile et pour les mêmes raisons. En fait, dans la pratique, modifier une mise en page est toujours difficile, et il ne suffit presque jamais de changer le code CSS si vous voulez faire quelque chose de plus grave que de simples modifications mineures. Vous aurez besoin de comprendre et de modifier la structure HTML pour les changements de conception graves. Et les tables ne rendent pas le travail plus difficile ou plus facile que les divs.

En fait, la seule façon pour moi de rendre les tableaux difficiles à modifier, c’est si vous les utilisiez et si vous créiez un désordre impie. Vous pouvez aussi le faire avec des divs.

Alors ... dans le but de changer cela d'un coup de gueule en une question cohérente: qu'est-ce qui me manque? Quels sont les avantages réels d'utiliser une "fausse table" par rapport à une vraie?

À propos du lien en double: Il ne s'agit pas d'une suggestion d'utiliser une autre balise ou quelque chose d'autre. Ceci est une question sur l' utilisation d' un <table>contre display:table.

C'est un modèle courant pour créer des tables réactives. Les données tabulaires sont difficiles à afficher sur les téléphones mobiles, car la page sera agrandie pour lire du texte, ce qui signifie que les tableaux sont décalés et que l'utilisateur doit faire défiler en avant et en arrière pour lire le tableau. Sinon, la page sera agrandie. , ce qui signifie généralement que la table est trop petite pour pouvoir lire.

Les tables réactives changent de présentation sur des écrans plus petits - parfois, certaines colonnes sont masquées ou fusionnées. Par exemple, le nom et l'adresse électronique peuvent être séparés sur de grands écrans, mais ils sont réduits en une seule cellule afin que les informations soient lisibles sans défilement.

<div>s sont utilisés pour créer les tables au lieu de <table>balises pour plusieurs raisons. Si des <table>balises sont utilisées, vous devez remplacer les styles et la présentation par défaut du navigateur avant d'ajouter votre propre code. Dans ce cas, les <div>balises permettent d'économiser beaucoup de CSS. En outre, les anciennes versions d'Internet Explorer ne vous autorisent pas à remplacer les styles de tableau par défaut. L'utilisation de <div>s adoucit également le développement multi-navigateurs.

Il y a un assez bon aperçu des tables responsive sur CSS-Tricks .

Edit: Je dois préciser que je ne préconise pas ce schéma - il tombe dans le piège du divitis et n’est pas sémantique - mais c’est pourquoi vous trouverez des tableaux fabriqués à partir de divs.

La question est de savoir si les données sont sémantiquement une table (c'est-à-dire un ensemble de données ou des unités d'informations organisées logiquement en deux dimensions) ou si vous utilisez simplement la grille pour une présentation visuelle, par exemple parce que vous souhaitez développer une barre latérale ou quelque chose du genre.

Si votre information est sémantiquement une table, vous utilisez une <table>-tag. Si vous souhaitez simplement une grille à des fins de mise en page, utilisez d'autres éléments HTML appropriés et utilisez-les display:tabledans la feuille de style.

Quand les données sont-elles sémantiquement une table? Lorsque les données sont logiquement organisées selon deux axes. Si cela se justifie avec des en-têtes pour les lignes ou les colonnes, alors vous pourriez avoir un tableau sémantique. Un exemple de quelque chose qui n'est pas sémantiquement un tableau présente un texte en colonnes comme dans un journal. Ce n'est pas sémantiquement une table, puisque vous la liriez toujours de manière linéaire, et aucune signification ne serait perdue si la présentation était supprimée.

OK, pourquoi ne pas utiliser <table>pour tout plutôt que pour quelque chose qui est sémantiquement une table? Visuellement, c'est évidemment la même chose (puisque l'élément de table a simplement display:elementdans la feuille de style par défaut).

La différence est que les informations sémantiques peuvent aider d'autres agents utilisateurs. Par exemple, un lecteur d'écran peut vous permettre de naviguer dans les deux dimensions du tableau et de lire les en-têtes d'une cellule pour les deux axes si vous oubliez où vous vous trouvez. Cela serait juste déroutant si la table n'était pas sémantiquement une table mais simplement utilisée pour une présentation visuelle.

La discussion <table>opposée display:tablen’est qu’un exemple du principe plus général d’utilisation du balisage sémantique. Voir par exemple: Pourquoi s'embêterait-il de marquer correctement et sémantiquement? ou Pourquoi les balises sémantiques ont-elles plus de poids pour les moteurs de recherche?

Dans certains endroits, vous pourriez être légalement tenu d'utiliser le balisage sémantique pour des raisons d'accessibilité, et dans tous les cas, il n'y a aucune raison de rendre votre page moins accessible.

Même si vous ne vous souciez pas des utilisateurs handicapés, une présentation séparée du contenu vous procure des avantages. Par exemple, votre mise en page à trois colonnes pourrait être présentée en une seule colonne sur un mobile en utilisant une feuille de style alternative.

En fait, je dirais que l'utilisation de noms de classe tels que "table" dans votre exemple montre que les gens ne comprennent pas vraiment ce qu'ils font lorsqu'ils essaient de balisage sémantique. Ils obtiennent des marques pour avoir essayé de montrer que le contenu ne correspond pas à des données tabulaires , mais ils la perdent pour les noms de classe incorrects.

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

Tout ce que ce développeur a fait est de répliquer le <table>balisage d' origine avec les noms de classes CSS. Cela signifie que dès que cette disposition n'est pas une table, les noms de classe sont en désaccord.

Ce développeur aurait dû se concentrer sur les informations contenues dans le tableau. S'agit-il d'une galerie de vignettes? Eh bien:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Maintenant, je peux créer des CSS adaptatifs:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Pourquoi divs et pas des tables

Une table contient des données tabulaires - la présentation d’une table est inextricablement liée à la structure d’une table. Les données tabulaires doivent toujours être sous forme tabulaire, quel que soit le lieu où vous placez ce contenu ou sur l'écran / le périphérique que vous souhaitez afficher.

Une galerie de vignettes (ou de nombreuses autres choses, comme un formulaire d'inscription, un menu, etc.) n'est pas une donnée tabulaire. Il peut être présenté comme une table dans certaines dispositions de conception, mais dans d'autres cas, comme des écrans de téléphone étroits, vous souhaitez utiliser des dispositions de bloc plus traditionnelles. Ou peut-être souhaitez-vous afficher des vignettes dans une barre latérale plutôt que dans la zone de contenu principale.

Vous avez maintenant le choix de générer un balisage différent pour le contenu grand écran (tableaux) et le contenu de barre latérale ou étroite (div), ce qui signifie que vos scripts côté serveur devront savoir où se trouve le contenu si vous le créez par programmation. - ou votre script côté serveur génère le même balisage (car il ne devrait pas se soucier de savoir où vous le mettez) et utilise des règles CSS différentes pour les différentes situations.

Vous avez donc le choix de toujours afficher les tables, puis de remplacer les règles d’affichage des tables naturelles par des blocs (ce qui devrait vraiment décourager certains développeurs), ou d’utiliser des divs bien étiquetés qui permettent des approches plus souples du style.

Et depuis plusieurs années, les meilleures pratiques consistent à éviter les tableaux s’il n’est pas nécessaire de présenter des données tabulaires.

Autrefois, le moteur de rendu de table " apparaissait " plus lentement lorsque vous utilisiez des pourcentages pour les largeurs de colonne. Le moteur devait essentiellement télécharger l'intégralité du jeu de données avant de commencer à déterminer l'ampleur de tout pour le dessiner à l'écran.

Le moteur de DIV était différent. Lorsque le navigateur rencontrait une DIV, il la mettait en place et commençait à remplir le contenu en ligne. Bien sûr, les div peuvent sauter lorsque les données sont chargées. D'où la raison pour laquelle je suis apparu entre guillemets ci-dessus. Le délai d'exécution des deux tâches était identique, mais les tableaux n'étaient pas complétés jusqu'à la fin, ce qui signifiait que l'utilisateur n'était pas certain de savoir s'il était en train d'être chargé ou non pendant une seconde ou deux.

Cela a empiré lorsque les tables ont été imbriquées.

Il existait alors (et existe toujours) des moyens de rendre le rendu de tableau plus rapide FAR FAR. Essentiellement, en lui indiquant que les tailles de colonne ne changent pas, le navigateur commence immédiatement à restituer les données tabulaires. En fin de compte, cela signifie que les tables peuvent afficher dans la bonne position plus rapidement que les div en leur donnant l’apparence d’être meilleures.

Mais ce n'est pas toute l'histoire. Le reste est que la plupart des développeurs ne se soucient tout simplement pas d'apprendre leur métier assez pour le savoir. Au lieu de cela, ils sautent sur différents types de bandes et utilisent le code qu'ils peuvent copier / coller. Même aujourd’hui, j’aperçois que très peu de développeurs Web connaissent la différence d’un doctype à l’autre - et c’est la principale raison pour laquelle différents sites proposent toutes sortes de solutions de contournement pour couvrir différents navigateurs.

Alors, +1 à vous pour avoir posé la question.

Si je peux obtenir un peu de "méta" ici, cela me pose deux problèmes:

Un: quelqu'un propose une règle pour une bonne raison, et les gens l'omportent complètement en suivant la lettre technique de la règle tout en ignorant l'esprit. Ils trouvent un moyen d’accomplir toutes les mauvaises choses que la règle tentait d’empêcher, tout en suivant techniquement la règle telle qu’elle était libellée.

Deux: quelqu'un voit un problème et propose une règle pour l'empêcher. D'autres voient la valeur de cette règle. Ensuite, ils insistent sur la dévotion aveugle à cette règle sans tenir compte du problème initial qu’elle était censée résoudre et / ou quels que soient les autres problèmes qu’elle crée. J'ai eu beaucoup de conversations où quelqu'un a dit: "Tu dois faire X parce que c'est la règle", puis je demande: "Mais pourquoi devrions-nous faire X?", Et ils me regardent avec perplexité et exaspération et disent: "Mais Je viens de te le dire! Parce que c'est la règle! " Je réponds: "Mais cela semble causer plus de problèmes qu'il n'en résout. Je pense que nous ferions mieux de faire Y." Et puis la personne dit: "Non, regardez, je vais vous montrer. Vous voyez, c'est ici dans ce livre. X est la règle."

Dans ce cas, nous avons un problème: la balise table a deux fonctions: premièrement, elle contrôle la mise en page d'un document. Deuxièmement, cela suggère que les données incluses sont constituées de lignes et de colonnes de nombres ou d’autres données.

Beaucoup de gens ont proposé la solution: n'utilisez pas de balises de table pour contrôler la disposition des éléments qui ne sont pas logiquement des "tables". Utilisez CSS.

Mais il y a un problème avec cette solution. La balise table et ses sous-étiquettes remplissent de nombreuses fonctions de mise en page très utiles, difficiles à utiliser avec CSS, et quand elles peuvent être réalisées, le code nécessaire pour le faire est souvent fastidieux, difficile à lire et à maintenir. Pourquoi devrions-nous faire les choses de manière maladroite et difficile quand il y a un moyen propre et facile?

Personnellement, je pense que nous aurions mieux fait de simplement déclarer: "Le fait que quelque chose se trouve à l'intérieur d'une balise de table ne signifie pas nécessairement qu'elle représente des lignes et des colonnes de nombres." Cela n'aurait pas été une déclaration scandaleuse. Je n'ai jamais entendu quelqu'un dire que la balise "p" ne puisse être utilisée que pour des choses qui sont en réalité des paragraphes de phrases anglaises construites logiquement et grammaticalement correctes. Je n'ai jamais entendu quelqu'un dire qu'il est faux d'utiliser une balise "ul" pour une liste qui vient en fait dans un ordre logique, simplement parce que vous vouliez des puces et non des numéros de séquence. Etc.

Il y a déjà des tonnes de bonnes réponses ici. Mais je voulais ajouter que les tableéléments ont des limitations de rendu qui n'existent pas pour les divéléments. Essayez de faire un tableau qui fait défiler virtuel (comme: SlickGrid , DataTables , et autres) et vous serez cruellement déçu. Ça ne marche pas. La plupart (tous?) Des grilles Javascript modernes utilisent divs parce que le css permet un rendu beaucoup plus souple.

Il y a aussi d'autres limitations. Ma règle générale est que si je veux voir la table entière sur un seul écran, et que je ne veux pas de rendu très personnalisé, j'utilise un tableélément, sinon je vais avec des divs parce que je peux contrôler beaucoup les résultats beaucoup plus facilement.

HTML et CSS ont évolué vers un degré de flexibilité qui signifie que même des éléments conceptuels de "bloc" tels que <div>(la forme la plus ancienne et la plus générale du contenu de bloc HTML) n'ont pas besoin d'être affichés sous forme de blocs:

div { display: inline; }

Comme vous le notez, <div>peut être réutilisé pour imiter <table>et ses compagnons de voyage. En fait, la plupart des tags peuvent. Compte tenu de leur rôle particulier, je doute que vous pourriez utilement remapper balises macro comme <html>, <head>, <body>et <script>, mais les balises « communs » comme <div>, <p>, <b>, <em>, <span>et <pre>? À gagner. Créez les blocs de balises en ligne, les blocs en ligne, les balises pré-formatées, les balises stationnaires flottent. Deviens fou si tu veux!

Il est possible . Vous voudrez peut-être expliquer comment nous devrions tous utiliser le "balisage sémantique" bla bla bla ou croire aux Pythonistes qu'il "devrait y avoir un - et de préférence un seul moyen évident de le faire." Pourtant, Tim Toady est un gars intelligent et curieux. Avec une main libre, il les explorera tous. Cela inclut l’utilisation de la flexibilité disponible pour effectuer des substitutions. Certains sont sages, d'autres prouveront le contraire. Mais les essais, les erreurs et l'expérience sont le seul moyen de le savoir. Donc, les conditions suffisantes pour la substitution sont présentes.

Je ne pense pas qu'il soit exagéré de dire que la substitution est également nécessaire. Au minimum, c'est extrêmement pratique . Pendant longtemps, HTML n'a pas eu <menu>, <section>ou des <aside>éléments. Pourtant, partout dans le monde, les pages Web et les applications comportent des menus, des sections et des barres latérales. Comment? Étant donné que la liste des éléments HTML ( <ul>, <ol>et <li>) ont été facilement réutilisés et certains usages reclassées comme des conteneurs de menu et pièces. <div>pourrait se substituer à <article>, <section>, <aside>, <figure>et <summary>. HTML5 a rattrapé et ajouté des éléments sur mesure pour certains cas d'utilisation non encore résolus. C'est une excellente mise à jour et correction pour s'adapter à une utilisation courante et réelle.

Malgré cela, il reste encore beaucoup d'idiomes communs qui n'ont pas de balises personnalisées ou de modèles sémantiques . Des choses comme les pages, les notes de bas de page, les citations à tirer, les flux de commentaires, les avatars associés, les "j'aime", les sous-titres et les sous-titres que moi et beaucoup d'autres utilisons chaque jour. Que devons-nous faire? Ce que nous pouvons Utilisez à nouveau des éléments «proches mais inexacts» avec des classes et des identifiants pour soutenir notre travail au cours des cinq, dix ou même nombreuses années jusqu'à ce que HTML6 ou HTML7 se rattrape. Le langage HTML / CSS "oui, en théorie, c'est un X, mais nous allons le baliser et l'utiliser avec un Y", ce qui est incroyablement pratique. Indispensable, vraiment. Cela rend le contenu Web flexible et non fragile.

Pour aller encore plus loin, le "balisage sémantique" a des limites irréductibles . C'est le cas de toute structure rigoureuse imaginable pour le contenu.

Les formats standard ne peuvent pas englober toute la richesse des besoins, des désirs et de la variété des êtres humains. Ils seront toujours "derrière la courbe" de ce que les gens font maintenant . Comment ils innovent. Heck, HTML5 est toujours derrière la courbe des notes de bas de page, sous-titres et autres innovations d'impression du 17ème siècle. Il manque des fonctionnalités essentielles pour de nombreux professionnels de l’information et créateurs de contenu. Alors on improvise.

Encore plus immuable, ces informations ne respectent pas un ensemble de règles. Bien sûr, ça commence comme une table. Mais vous voulez peut-être simplement le résumé - dites le titre de chaque ligne, sous forme de liste. Cela prend peut-être trop de place et vous voudriez une liste en ligne peu encombrante. Peut-être que vous avez des enregistrements dont vous voulez seulement le titre, puis si vous cliquez sur, vous voyez les détails sous-jacents. Ou vous souhaitez que les éléments d'une liste ou d'un tableau complexe soient regroupés et classés. Oh, maintenant vous voulez que cela soit transposé et catégorisé différemment. Ou les valeurs tracées sous forme de graphique à barres. Ce sont des choses faites tous les jours dans les applications, les feuilles de calcul et la visualisation de données. Ils font partie intégrante de notre paysage informationnel et de ce que nous voulons et devons faire sur le Web. Les humains réorganisent constamment la forme et la présentation de nos données. Ce n'est pas juste une chose, ou un format / mise en page, ou un concept. C'est fongible, la sémantique dépendant des circonstances et des choix que les utilisateurs font de manière interactive. Oui, marquer le texte comme "souligné" (<em>), mais ce n’est qu’une convention. J'ai travaillé sur des documents avec au moins une demi-douzaine de types d'emphase différents. Nous devons pouvoir personnaliser et remapper cela pour différentes utilisations, différentes interprétations. Un type d'emphase HTML? Atrocement réductionniste. Limiter Fragile. La même chose est vrai pour <table>, <p>etc.

C'est génial d'avoir des tags / éléments qui aident à organiser la réflexion de toute la communauté sur "ce qui se passe où." Cela aide à établir des conventions et des idiomes et nous rend collectivement plus efficaces. Mais la capacité de remapper les choses, de redéfinir et de réorienter ces structures? Cela fait partie intégrante de l'inclusivité du Web et de son succès.

Les cas d'utilisation importent. Il y a une grande différence entre la disposition / présentation dans une page de contenu et dans une application. Dans le contenu, la sémantique compte beaucoup pour la connaissance du référencement et la convivialité. Dans ces cas, utiliser des tableaux pour présenter des données tabulaires est généralement la bonne chose à faire. Comme d'autres l'ont noté, les moteurs de recherche vont vous pénaliser et vous pouvez même enfreindre les lois sur l'utilisabilité si la loi vous oblige à vous conformer aux directives d'utilisation du gouvernement.

Dans une application Web, les développeurs peuvent choisir de créer des vues entièrement distinctes à des fins de référencement et de convivialité. La conception réactive a amené les utilisateurs à créer des vues capables de gérer les dispositions de bureau et mobiles, et les div sont meilleures que les tables dans ces cas d'utilisation.

Prenez les sites de commerce électronique, par exemple. L'affichage d'une liste de produits dans un résultat de recherche ou de navigation affiche, en général, une liste de produits au format tabulaire, mais ces vues peuvent être générées à l'aide de divs (qui fournissent des options de mise en page et de style plus génériques et flexibles) plutôt que des tableaux. Amazon et eBay sont de bons exemples de cette approche. Inspectez un résultat de recherche sur l'un ou l'autre site et vous verrez un ensemble profondément imbriqué de div.