Pourquoi les gens font des tables avec des divs?

269

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.

Vilx-
la source
6
@JuhaUntinen: cela ... semble peu probable. La source?
Paul D. Waite
5
@ PaulD.Waite - Je pense que c'est encore vrai aujourd'hui. Lisez les autres réponses. À moins que la table ne l’ait été table-layout:fixed, elle devra être entièrement chargée avant de pouvoir être affichée. Avec le haut débit moderne, cet effet est simplement moins perceptible.
Vilx-
4
@JuhaUntinen: Ce n'est pas tout à fait exact. Le moteur de rendu de la table était plus lent lorsque vous utilisiez des pourcentages pour la largeur des colonnes, car la totalité de la table devait être téléchargée avant que le navigateur ne puisse commencer à déterminer la taille de la création. C'était compliqué par des tables imbriquées. Cependant, il existait alors (et existe toujours) des moyens de rendre le rendu de tableau plus rapide FAR FAR. Très peu de développeurs se donnent la peine d’apprendre suffisamment à maîtriser leur métier et à sauter à la place.
NotMe
4
À l'époque plus ancienne encore, nous imitions les divs avec des tables, donc là-bas.
Wyatt Barnett
4
Quelqu'un a lu qu'ils n'étaient pas censés utiliser des tableaux pour la mise en page et que cela signifiait qu'ils n'étaient pas censés utiliser des tableaux du tout. Je déteste cette tendance.
Casey

Réponses:

120

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.

whostolemyhat
la source
6
J'accepte cette réponse car il semble que rien d'autre d'utile ne soit entré. Il y a des réponses plus votées, mais elles disent essentiellement "à cause de la sémantique" (et la seule raison pour laquelle elles peuvent fournir une sémantique est la lecture d'écran, ce qui ne me convainc pas). La réponse de @ HorusKol a mentionné la réactivité avant la vôtre, mais la vôtre est plus pertinente. Si une meilleure réponse apparaît dans le futur, je changerai cela pour être celle acceptée.
Vilx-
5
C'est ridicule et paresseux. Tout ce que vous faites avec des <div>“tables” pourrait probablement être fait avec des tables ordinaires. Il n'y a donc aucune raison (hormis les anciennes versions d'IE et la paresse) d'utiliser des éléments non sémantiques pour construire des tables. Cela dit, les données tabulaires réelles semblent rares sur Internet, alors c'est peut-être un problème.
Vous
1
@Vilx: La question que vous avez posée est "Pourquoi les gens font- ils des tables avec des divs", ce à quoi vous obtenez des réponses. Par exemple, vous ne vous souciez peut-être pas des lecteurs d'écran, mais cela ne change rien au fait que l'accessibilité est une préoccupation réelle pour beaucoup, et (avec les moteurs de recherche) la principale raison pour laquelle de nombreuses personnes choisissent le HTML sémantique.
JacquesB
13
À toutes fins utiles, c'est tout simplement faux. Si vos données sont tabulaires, elles vont dans un tableau. BS prétend que les tables se comportent particulièrement mal sur un appareil mobile. Vous pouvez tout aussi facilement modifier les propriétés d'affichage des éléments de table en valeurs non-table que vous pouvez faire en sorte que les éléments non-table aient des valeurs de table.
Cimmanon
8
Je crois que cette réponse est légèrement trompeuse. Les tables réactives sont bien conçues, mais elles ne dépendent pas de la question de savoir si vous devez utiliser <table> ou <div> - vous pouvez utiliser le même effet visuel. En effet, ceci est au cœur de l'idée de séparation de la structure et de la présentation. Il est vrai que les anciennes versions d'IE n'autorisaient pas le style de table, mais que les anciennes versions ne supportaient pas non plus display: table, vous ne pouviez donc pas utiliser de tables responsive.
JacquesB
153

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.

JacquesB
la source
14
@ Vilx, pourquoi utiliser <em>et <strong>plutôt que <b>et <i>? Parce que <b>et <i>ne concernent pas la sémantique de la balise. <table>a une signification sémantique . Son utilisation pour quelque chose qui n'est pas une table rend plus difficile la compréhension de la signification sémantique du document.
22
@ Vilx- The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. Mettre <i>dans le meilleur serait erroné parce que cela signifie quelque chose de différent que le <i>autour du titre du livre. Pour plus d'informations, voir Pourquoi les balises <b>et sont <i>obsolètes? et Quelle est la différence entre <b>et <strong>, <i>et <em>?
19
Si vous ne vous souciez pas de la signification de votre contenu, je vous suggère fortement de cesser d'utiliser des éléments, à l'exception des formulaires et des div. Ajoutez simplement des classes pour appliquer le style et le comportement.
Rich Remer
9
@ Vilx-: Lorsque vous dites que vous vous souciez de l'expérience de vos utilisateurs, vous semblez ne parler que d'un sous-ensemble de vos utilisateurs. La principale raison d'utiliser correctement le balisage dans votre description est pour l'accessibilité, qui est directement liée à l'expérience utilisateur des utilisateurs handicapés. Ce sont les personnes qui bénéficient de ce que vous faites de la bonne façon. Ignorer ces conventions signifie probablement rendre leur expérience Web plus difficile.
Rooby
31
@ Vilx-, oui, un lecteur d'écran traite une <table> de manière très différente d'un <div>. Les <div> s sont généralement ignorés et lus de manière séquentielle. Dans une <table>, il doit fournir différentes séquences de touches / commandes de navigation ("Aller à la cellule à droite", "Lire le titre des colonnes et des lignes", etc.), et exprimer différentes informations d'emplacement (lorsque le flux de lecture entre dans un tableau cela ressemble à "Tableau 3, rangée 1 colonne 1, Lorem Ipsum dolor ... ")
Euro Micelli
102

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.

HorusKol
la source
Les noms de classe n'étaient en réalité qu'un exemple. Dans la vie réelle, ils sont généralement bien descriptifs. Quoi qu'il en soit, dans votre exemple, pourquoi utilisez-vous à la <div>place de <table>? Quels avantages offre-t-il?
Vilx-
1
Hmm ... eh bien, dans votre cas, vous faites en fait deux représentations différentes du même HTML via des requêtes multimédia. OK, c'est un bon cas d'utilisation. Mais si ce n’était pas le cas, et que vous sauriez à l’avance que cette galerie de vignettes ne sera affichée qu’à un seul endroit et que sous forme de tableau - utiliseriez-vous <table>alors ou encore display:table? Parce que d'une certaine manière, ce sont des données tabulaires. Sauf que les "données" sont des images, mais quand même.
Vilx-
15
Eh bien, non, ce ne sont pas des données tabulaires. vous le présentez dans une grille qui ressemble à une table. Les données tabulaires sont des statistiques et des informations comparatives - pensez comme un tableur. Diriez-vous que la vue miniature dans l'explorateur de fichiers Windows correspond à des données tabulaires? Et, cela sera-t-il toujours présenté comme une table? Et si vous voulez un style de vue différent dans 6 ou 12 mois? Pourquoi imposer des restrictions qui ont des effets à long terme dans le but de s’obstiner face à des pratiques largement acceptées?
HorusKol
12
Sauf que ce ne sont pas des données tabulaires, du tout. Il n'y a aucune autre raison qu'une décision de disposition arbitraire que ce contenu ressemble à une table. Ce ne sont pas des données structurées en colonnes et en lignes, c'est une liste de contenu, disposées dans une grille. - edit: Ce que HorusKol a dit.
Eric King
3
Bon, d'accord, ça l'étirait un peu. :) Eh bien, vous m'avez donné à réfléchir! Merci pour ça! Je ne suis toujours pas convaincu à 100%, mais au moins c'est une chose à faire. :)
Vilx-
11

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.

Pas moi
la source
Offtopic à propos de DOCTYPE: Je pensais que, bien qu'il y ait une différence théorique (et que les validateurs l'ont prise au sérieux), dans la pratique, les navigateurs ne les distinguaient pas vraiment. OK, peut-être y a-t-il eu quelques changements mineurs entre les versions HTML / XHTML, mais la version et les informations de la DTD n'ont pas été utilisées. C’est la raison pour laquelle HTML5 a tout de même abandonné l’ensemble du processus et <!DOCTYPE html>c’est pourquoi il fonctionne même dans les anciens navigateurs comme IE6. Ai-je raté quelque chose?
Vilx
2
@Vilx: un doctype met un navigateur dans un certain mode. Entre autres choses, il définit le modèle de boîte utilisé. Pour un certain nombre de doctypes, les navigateurs ne s'alignaient pas car le modèle de boîte utilisé était différent. C'est pourquoi tant de développeurs se sont plaints que les navigateurs affichaient les pages différemment et que, plutôt que de corriger le doctype, utilisaient des feuilles de réinitialisation css massives. Cependant, il y a eu quelques doctypes dans lesquels tous les navigateurs utilisaient le même modèle de boîte - mais ceux-ci n'étaient jamais la valeur par défaut, vous deviez les connaître.
NotMe
@vilx: html 5 n'a pas tout lâché. Au lieu de cela, un nouveau doctype a été ajouté. Le fait est que la toute première ligne qui apparaît en haut du document html est essentielle. Si vous ne comprenez pas ce qu’il fait et comment réagissent les différents navigateurs, vous passerez beaucoup trop de temps à comprendre pourquoi votre mise en page. est "cassé" dans un navigateur particulier.
NotMe
Attendez, alors il y a différents doctypes qui font que le même document soit rendu différemment? Lesquels? Remarquez que je parle de doctypes différents, pas de doctype contre le manque de doctype (alias Quirksmode).
Vilx-
@Vilx: C'est un peu plus compliqué, car certains doctypes déclenchent le mode quirks (comme aucun doctype) et d'autres doctypes (y compris le doctype html5) déclenchent le mode standard, et même certains doctypes déclenchent un troisième "presque standard" "mode dans certains navigateurs.
JacquesB
5

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.

Geai
la source
7
WR jusqu'au dernier paragraphe - vous avez lu les spécifications HTML5 pour ces éléments, n'est-ce pas? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / drafts / html / master / semantics.html # l'élément -ol-element - particulièrement si l'ordre a de l'importance, utilisez l'élément ol (puisqu'il s'agit de la partie structurelle) - vous pouvez toujours le présenter sous forme de liste à puces en utilisant CSS
HorusKol
5
et si vous regardez les deux autres réponses ici, vous verrez que ni l'une ni l'autre ne dit simplement "parce que c'est la règle" - elles expliquent toutes les deux très clairement la règle et les cas d'utilisation
HorusKol
1
Hmm, il me semble que j’ai dit quelque chose du genre: "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 pour que la règle soit dévouée à l'aveuglette sans se soucier du problème initial supposé. résoudre et / ou quels que soient les autres problèmes que cela crée ". Je ne nie pas qu'il existe une pensée raisonnable derrière la règle. Je ne suis tout simplement pas d'accord avec la conclusion. Je peux sûrement dire: "Vous avez un bon point à ce sujet, mais néanmoins je ne suis pas d'accord." Et vous ne niez sûrement pas qu'il y ait des gens qui ne comprennent pas le pour et le contre et qui disent ...
Jay
1
... "parce que c'est la règle". J'ai eu plusieurs conversations avec de telles personnes au fil des ans, sur cette question en particulier et sur bien d'autres. Les personnes qui refusent même de discuter des avantages et des inconvénients d'une règle, parce que c'est la règle, la fin de la discussion.
Jay
Il est apparu cette notion malheureuse selon laquelle le design HTML tire ses racines d'une forme d'ingénierie abstraite plutôt que d'art. En tant que tels, certains ont décidé qu'il devait exister des règles absolues analogues à la physique et qu'il fallait obéir à la gravité , sinon quelqu'un qui enfreint de telles règles est écarté de la "foi plus pure". La réalité est qu’aucune métaphore de navigateur ni de conception n’est infaillible. Marchez prudemment auprès de ceux qui insistent pour le contraire.
David W
5

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.

Crisfole
la source
3

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.

Jonathan Eunice
la source
4
en quoi cela vous rapproche-t-il de la réponse à la question?
HorusKol
2
OMI, il aborde la question sous-jacente de la raison pour laquelle les concepteurs, les développeurs et les travailleurs du contenu choisissent d'utiliser des éléments génériques ( <div>et <span>) à la place d'éléments spécifiques conçus à cet effet (par exemple <table>). C'est un peu plus méta que ces balises, mais cela concerne directement les modèles et les principes d'utilisation.
Jonathan Eunice
@HorusKol En fait, parmi toutes les réponses données ici, celle-ci est la plus cohérente et la plus favorable à votre réponse. Je dirais qu'ils s'emboîtent bien.
Jonathan Eunice
1
Je ne sais pas si j'irais jusqu'à opposer div(comme générique) à table(comme construit à cet effet). Ils sont tous deux construits à des fins spécifiques, pour deux finalités différentes (qui se chevauchent peut-être partiellement). Je pense que ceci est le coeur de la question.
Eric King
@ EricKing Il est juste de dire que cela diva un but. Mais divet spanne pas la très spécifique destination que table, thead, tdetc faire. Personne ne paniquera si vous utilisez des divéléments divers pour les barres latérales, les guillemets, les groupements de sections, etc., pratiquement n'importe où dans le document. Essayez de faire ça avec un unenclosed thead, tdou li. Au lieu de "construit à cet effet", peut-être "spécifique à un but" ou "avec un rôle spécifique prévu".
Jonathan Eunice
0

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.

Robert Munn
la source