Pourquoi les gens font-ils des tables avec des divs?
Dans le développement Web moderne, je rencontre de plus en plus 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 ne sont qu'illustratifs; dans la vraie vie, ce sont des noms de classe normaux reflétant le sujet de l'élément)
J'ai même essayé de le faire moi-même récemment 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 simplement un _ <table> et en finir. Oui, même si c'est pour la mise en page. C'est à cela que servent les tableaux - disposer les choses de manière tabulaire.
La meilleure explication que j'ai est que maintenant tout le monde a entendu le mantra de "ne pas utiliser de tableaux pour la mise en page", alors ils le suivent aveuglément. Mais ils ont toujours besoin d'une table pour la mise en page (car rien d'autre n'a les capacités d'extension d'une table), donc ils font un <div> (parce que c'est pas une table!) puis ajoutez CSS qui en fait quand même une table.
Pour le monde entier, cela me semble mettre des obstacles arbitraires inutiles sur votre chemin, puis faire un travail supplémentaire pour les contourner.
L'argument original pour s'éloigner des tableaux pour la mise en page était qu'il était difficile de modifier une mise en page 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 simplement changer le CSS, si vous voulez faire quelque chose de plus sérieux que des ajustements mineurs. Vous aurez besoin de comprendre et de modifier la structure HTML pour des changements de conception importants. Et les tables ne rendent pas le travail plus difficile ou plus facile que les divs.
En fait, la seule façon dont je vois que les tableaux peuvent rendre une mise en page difficile à modifier, c'est si vous un Bles a utilisés et a créé un désordre impie. Vous pouvez aussi le faire avec des divs.
Alors ... pour essayer de changer cela d'une diatribe en une question cohérente: qu'est-ce qui me manque? Quels sont les avantages réels de l'utilisation d'une "fausse table" par rapport à une vraie?
À propos du lien en double: Ce n'est pas une suggestion d'utiliser une autre balise ou quelque chose. Il s'agit d'une question sur l'utilisation d'un <table> contre display:table.
Il s'agit d'un modèle courant pour créer des tableaux réactifs. Les données tabulaires sont difficiles à afficher sur les mobiles, car la page sera agrandie pour lire le texte, ce qui signifie que les tableaux disparaissent du côté de la page et l'utilisateur doit faire défiler vers l'arrière et vers l'avant pour lire le tableau, ou la page sera dézoomée , ce qui signifie généralement que la table est trop petite pour pouvoir lire.
Les tableaux réactifs changent la disposition sur des écrans plus petits - parfois certaines colonnes sont masquées ou les colonnes sont fusionnées, par exemple le nom et l'adresse e-mail peuvent être séparés sur de grands écrans, mais se réduire en une seule cellule sur de petits écrans afin que les informations soient lisibles sans avoir à faire défiler.
<div>s sont utilisés pour créer les tables au lieu de <table> tags pour plusieurs raisons. Si <table> les balises sont utilisées, vous devez remplacer les styles et la disposition par défaut du navigateur avant d'ajouter votre propre code. Dans ce cas, <div> les balises permettent d'économiser sur beaucoup de CSS standard. De plus, les anciennes versions de IE ne vous permettent pas de remplacer les styles de tableau par défaut, donc en utilisant <div>s facilite également le développement multi-navigateur.
Il y a un assez bon aperçu des tableaux réactifs sur CSS-Tricks .
Edit: je dois souligner que je ne préconise pas ce modèle - il tombe dans le piège de la divite 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 un tableau (c'est-à-dire un ensemble de données ou d'unités d'informations organisées logiquement en deux dimensions) ou si vous utilisez simplement la grille pour la présentation visuelle, par ex. parce que vous voulez développer une barre latérale ou quelque chose comme ça.
Si vos informations sont sémantiquement un tableau, vous utilisez un <table>-étiquette. Si vous voulez juste une grille à des fins de mise en page, vous utilisez d'autres éléments html appropriés et utilisez display:table dans la feuille de style.
Quand les données sont-elles sémantiquement une table? Lorsque les données sont organisées logiquement selon deux axes. Si cela a du sens avec des en-têtes pour les lignes ou les colonnes, vous pouvez avoir une table sémantique. Un exemple de quelque chose qui n'est pas sémantiquement un tableau présente un texte dans des colonnes comme dans un journal. Ce n'est pas sémantiquement un tableau, car vous le liriez toujours linéairement, 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 table a juste display:element dans la feuille de style par défaut).
La différence est que les informations sémantiques peuvent aider les agents utilisateurs alternatifs. Par exemple, un lecteur d'écran peut vous permettre de naviguer en deux dimensions dans le tableau et de lire les en-têtes d'une cellule pour les deux axes si vous oubliez où vous êtes. Ce serait tout simplement déroutant si la table n'était pas sémantiquement une table mais juste utilisée pour la mise en page visuelle.
Le <table> contre display:table la discussion n'est qu'un exemple du principe plus général d'utilisation du balisage sémantique. Voir par exemple: Pourquoi se donnerait-on la peine de marquer correctement et sémantiquement? ou Pourquoi le balisage sémantique donne-t-il plus de poids aux 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 délibérément votre page moins accessible.
Même si vous ne vous souciez pas des utilisateurs handicapés, une présentation distincte du contenu vous offre des avantages. Par exemple. votre disposition à trois colonnes peut être présentée dans une seule colonne sur un mobile à l'aide d'une autre feuille de style.
En fait, je dirais que l'utilisation de noms de classe comme "table" dans votre exemple montre comment les gens ne comprennent pas vraiment ce qu'ils font lorsqu'ils essaient de baliser sémantique. Ils obtiennent des notes pour avoir essayé de montrer que le contenu n'est pas des données tabulaires , mais ils perdent des marques pour les mauvais noms de classe.
<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 l'original <table> balisage avec les noms de classe CSS. Cela signifie que dès que cette disposition n'est pas une table, les noms de classe sont en désaccord.
Ce que ce développeur aurait dû faire est de considérer 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 du CSS adaptatif:
@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 les divs et non les tables
n tableau contient des données tabulaires - la présentation d'un tableau est inextricablement liée à la structure d'un tableau. Les données tabulaires devront toujours être sous forme tabulaire, peu importe où vous placez ce contenu ou sur quel écran/appareil vous souhaitez qu'il affiche.
Une galerie de miniatures (ou bien d'autres choses, comme un formulaire d'inscription, un menu, etc.) n'est pas des données tabulaires. Il peut être présenté comme un tableau dans certaines dispositions de conception, mais dans d'autres cas, comme les écrans de téléphone étroits, vous souhaitez qu'il utilise des dispositions de blocs plus traditionnelles. Ou vous souhaitez peut-être afficher les vignettes dans une barre latérale plutôt que dans la zone de contenu principale.
Votre choix est maintenant de générer un balisage différent pour le contenu grand écran (tableaux) et la barre latérale ou le contenu écran étroit (divs) - ce qui signifie que vos scripts côté serveur devront savoir où va le contenu si vous le construisez par programme - ou votre script côté serveur génère le même balisage (car il ne devrait pas se soucier de l'endroit où vous le mettez) et utilise des règles CSS différentes pour les différentes situations.
Ainsi, vous avez le choix de toujours générer des tableaux, puis de remplacer les règles d'affichage des tables naturelles par un bloc (qui devrait vraiment rectifier certains engrenages dans la tête de n'importe quel développeur), ou d'utiliser des divs bien étiquetés qui permettent des approches plus flexibles du style.
Et les meilleures pratiques depuis plusieurs années maintenant a été d'éviter les tableaux lorsqu'ils n'ont pas besoin de présenter des données tabulaires.
Autrefois, le moteur de rendu de table "appar" était plus lent lorsque vous utilisiez des pourcentages pour les largeurs de colonne. Le moteur devait essentiellement télécharger l'ensemble des données avant de commencer à déterminer la taille de tout pour le dessiner à l'écran.
Le moteur DIV était différent. Au fur et à mesure que le navigateur rencontrait un DIV, il allait le placer et commencer à remplir le contenu en ligne. Bien sûr, les div peuvent sauter lorsque le chargement des données est terminé. D'où la raison pour laquelle je suis apparu dans les citations ci-dessus. Le délai pour l'achèvement des deux était le même, mais les tableaux n'étaient pas dessinés jusqu'à la fin, ce qui signifiait que l'utilisateur n'était pas sûr s'il se chargeait ou non pendant une seconde ou deux.
Cela a empiré à mesure que les tables étaient imbriquées.
Il existait alors (et existe toujours) des moyens de rendre le rendu des tables FAR FAR plus rapide. Fondamentalement, en lui donnant un indice que la taille des colonnes ne change pas, le navigateur commence immédiatement à rendre les données tabulaires. En fin de compte, cela signifie que les tableaux peuvent réellement s'afficher dans la bonne position plus rapide que les divs, ce qui leur donne l'apparence d'être meilleurs.
Mais ce n'est pas toute l'histoire. Le reste est que la plupart des développeurs ne prennent tout simplement pas la peine d'apprendre leur métier assez bien pour le savoir. Au lieu de cela, ils sautent sur divers fourgons et utilisent le code à partir duquel ils peuvent copier/coller. Aujourd'hui encore, je constate que très peu de développeurs Web connaissent la différence d'un doctype à l'autre - et c'est la raison numéro un pour laquelle différents sites ont toutes sortes de solutions pour couvrir divers 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 manquent complètement le point 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 est 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 une dévotion aveugle à cette règle sans égard au 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 de nombreuses conversations où quelqu'un dit: "Vous devez 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, regarde, je vais te montrer. Tu vois, c'est juste ici dans ce livre. X est la règle."
Dans ce cas, nous avons un problème: la balise table fait deux choses: Premièrement, elle contrôle la mise en page d'un document. Deuxièmement, il transmet l'idée que les données jointes 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 choses 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-balises remplissent de nombreuses fonctions de mise en page très utiles qui ne sont pas faciles à réaliser en utilisant CSS, et lorsqu'elles peuvent être obtenues, le code nécessaire pour le faire est souvent lourd - difficile à lire et difficile à maintenir. Pourquoi devrions-nous faire les choses d'une manière maladroite et difficile alors qu'il existe une manière propre et facile?
Personnellement, je pense que nous aurions mieux fait de déclarer simplement: "Le fait que quelque chose se trouve à l'intérieur d'une balise de table ne signifie pas nécessairement qu'il 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 peut être utilisée que pour des choses qui sont vraiment des paragraphes de phrases anglaises grammaticalement correctes et logiquement construites. Je n'ai jamais entendu quelqu'un dire qu'il est mal d'utiliser une balise "ul" pour une liste qui, en fait, vient dans un ordre logique, juste parce que vous vouliez des puces et non des numéros de séquence. Etc.
Il y a déjà tonnes de bonnes réponses ici. Mais je voulais ajouter que les éléments table ont des limitations de rendu qui n'existent pas pour les éléments div. Essayez de créer un tableau qui fait du défilement virtuel (comme: SlickGrid , DataTables , et autres) et vous serez cruellement déçu. Cela ne fonctionne tout simplement pas. La plupart des grilles Javascript modernes (toutes?) Utilisent divs car le CSS permet un rendu beaucoup plus flexible.
Il existe également 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 personnalisé/beaucoup pour cela, j'utilise un élément table, sinon je vais avec des divs parce que Je peux contrôler les résultats beaucoup plus facilement.
HTML et CSS ont évolué vers une certaine flexibilité, ce qui signifie que même des éléments conceptuels "bloquent" comme <div> (La forme de contenu de bloc la plus ancienne et la plus générale de HTML) n'a pas besoin d'être affichée sous forme de blocs:
div { display: inline; }
Comme vous le constatez, <div> peut être réutilisé pour émuler <table> et ses compagnons de voyage. En fait, la plupart des balises le peuvent. Compte tenu de leurs rôles spéciaux, je doute que vous puissiez utilement remapper les balises de macro comme <html>, <head>, <body>, et <script>, mais des balises "courantes" comme <div>, <p>, <b>, <em>, <span>, et <pre>? À gagner. Faites flotter les blocs de balises en ligne, les blocs en ligne, les balises pré-formatées, les flottantes stationnaires. Deviens fou, si tu veux!
C'est possible . Vous voudrez peut-être faire tourner un fil sur la façon dont nous devrions tous utiliser le "balisage sémantique" blah blah blah, ou croire avec les Pythonistas qu'il "Il devrait y avoir une - et de préférence une seule - évidente façon 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, certains seront prouvés autrement. Mais les essais, les erreurs et l'expérience sont le seul moyen de le découvrir. Les conditions suffisantes de substitution sont donc réunies.
Je ne pense pas qu'il soit excessif de dire que la substitution est également nécessaire. Au minimum, c'est extrêmement pratique . Pendant longtemps, HTML n'avait pas <menu>, <section>, ou <aside> éléments. Pourtant, les pages Web et les applications ont partout des menus, des sections et des barres latérales. Comment? Parce que les éléments de liste HTML (<ul>, <ol>, et <li>) ont été facilement réaffectés et certains usages ont été reclassés comme conteneurs et parties de menu. <div> pourrait remplacer <article>, <section>, <aside>, <figure>, et <summary>. HTML5 a rattrapé et ajouté des éléments sur mesure pour certains cas d'utilisation non traités auparavant. C'est une excellente mise à jour et correction pour s'adapter à une utilisation courante dans le monde réel.
Même ainsi, il reste beaucoup d'idiomes communs qui n'ont pas de balises sur mesure ou de modèles sémantiques . Des choses comme les pages, les notes de bas de page, les pull-quotes, 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 tous les jours. Que devons-nous faire? Ce que nous pouvons. Réutilisez les éléments "proches mais inexacts" avec des classes et des identifiants pour qu'ils remplacent et soutiennent notre travail pendant les cinq ou dix prochaines années ou autant d'années jusqu'à ce que HTML6 ou HTML7 rattrape. HTML/CSS "oui, c'est un X, en théorie, mais nous allons le marquer et travailler avec lui comme un Y" est incroyablement pratique. Indispensable, vraiment. Il rend le contenu Web flexible et non fragile.
Pour aller encore plus loin, le "balisage sémantique" a des limites irréductibles . Cela est vrai de tout type de structure rigoureuse que vous pouvez imaginer pour le contenu.
Les formats standard ne peuvent pas englober toute la richesse des besoins humains, du désir et de la variété. Ils seront toujours "derrière la courbe" de ce que font les gens maintenant. Comment ils innovent. Heck, HTML5 est toujours en retard sur les notes de bas de page, les sous-titres et autres innovations d'impression du 17ème siècle. Il manque des fonctionnalités essentielles à de nombreux travailleurs de l'information et créateurs de contenu. Alors on improvise.
Encore plus immuable, les informations ne respectent pas un ensemble de règles. Bien sûr, cela commence comme une table. Mais peut-être que vous voulez juste le résumé - dites le titre de chaque ligne, sous forme de liste. Peut-être que cela prend trop de place, et vous l'aimeriez comme une liste en ligne peu encombrante. Peut-être que vous avez des enregistrements dont vous voulez juste 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 qu'il soit transposé et catégorisé d'une manière différente. 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 des données. Ils font partie intégrante de notre paysage de l'information 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 seulement 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, marquez 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 différents d'accentuation. Nous avons besoin de pouvoir personnaliser et remapper cela pour différentes utilisations, différentes interprétations. Un type d'accentuation HTML? Atrocement réductionniste. Limiter. Fragile. Il en va de même pour <table>, <p>, etc.
C'est formidable d'avoir des balises/éléments qui aident à organiser la réflexion de la communauté entière sur "ce qui va 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éutiliser ces structures? Cela fait partie intégrante de l'inclusivité du Web et de son succès.
Les cas d'utilisation comptent. Il existe une grande différence entre la mise en page/présentation dans une page de contenu et dans une application. Dans le contenu, la sémantique est très importante pour la prise de conscience SEO et la convivialité. Dans ces cas, l'utilisation de 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 vous pénaliseront et vous pouvez même enfreindre les lois sur l'utilisabilité si vous êtes tenu par la loi de vous conformer aux directives du gouvernement en matière d'ergonomie.
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 conduit les gens à créer des vues qui peuvent gérer les dispositions de bureau et mobiles, et les divs sont meilleures que les tableaux dans ces cas d'utilisation.
Prenons l'exemple des sites de commerce électronique. L'affichage d'une liste de produits dans un résultat de recherche ou de recherche affiche, en général, une liste de produits au format tabulaire, mais ces vues peuvent très bien être générées à l'aide de divs (qui offrent 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 de divisions profondément imbriquées.