Question Pourquoi ne pas utiliser les tableaux pour la mise en page en HTML? [fermé]


Il semble être le opinion générale les tables ne doivent pas être utilisées pour la mise en page en HTML.

Pourquoi?

Je n'ai jamais (ou rarement pour être honnête) vu de bons arguments pour cela. Les réponses habituelles sont:

  • C'est bon de séparer le contenu de la mise en page
    Mais c'est un argument fallacieux; Cliché Pensée. Je suppose que c'est vrai que l'utilisation de l'élément de table pour la mise en page a peu à voir avec les données tabulaires. Et alors? Est-ce que mon patron s'en soucie? Est-ce que mes utilisateurs s'en soucient?

    Peut-être moi ou mes collègues développeurs qui doivent entretenir une page web ... Une table est-elle moins facile à entretenir? Je pense que l'utilisation d'une table est Plus facile que d'utiliser divs et CSS.

    Au fait ... pourquoi utiliser un div ou un span une bonne séparation du contenu de la mise en page et une table non? Obtenir une bonne mise en page avec seulement des divs nécessite souvent beaucoup de divs imbriqués.

  • Lisibilité du code
    Je pense que c'est l'inverse. La plupart des gens comprennent HTML, peu comprennent CSS.

  • Il est préférable pour le référencement de ne pas utiliser les tables
    Pourquoi? Quelqu'un peut-il montrer des preuves que c'est? Ou une déclaration de Google que les tables sont découragées d'un point de vue SEO?

  • Les tables sont plus lentes.
    Un élément tbody supplémentaire doit être inséré. Ceci est des arachides pour les navigateurs Web modernes. Montrez-moi quelques repères où l'utilisation d'une table ralentit considérablement une page.

  • Une révision de la disposition est plus facile sans tables, voir css Zen Garden.
    La plupart des sites Web qui nécessitent une mise à niveau ont également besoin d'un nouveau contenu (HTML). Les scénarios dans lesquels une nouvelle version d'un site Web n'a besoin que d'un nouveau fichier CSS sont peu probables. Zen Garden est un site sympa, mais un peu théorique. Sans parler de son abuser de CSS.

Je suis vraiment intéressé par de bons arguments pour utiliser divs + CSS au lieu de tables.


665


origine


Réponses:


Je vais passer en revue vos arguments l'un après l'autre et essayer de montrer les erreurs qu'ils contiennent.

Il est bon de séparer le contenu de la mise en page   Mais c'est un argument fallacieux; Cliché Pensée.

Ce n'est pas du tout fallacieux parce que HTML a été conçu intentionnellement. L'utilisation abusive d'un élément n'est peut-être pas totalement hors de question (après tout, de nouveaux idiomes se sont développés dans d'autres langues), mais les éventuelles conséquences négatives doivent être contrebalancées. En outre, même s'il n'y avait pas d'arguments contre l'abus de la <table> élément aujourd'hui, il pourrait y avoir demain à cause de la façon dont les vendeurs de navigateur appliquent un traitement spécial à l'élément. Après tout, ils savent que "<table> les éléments sont uniquement pour les données tabulaires »et pourraient utiliser ce fait pour améliorer le moteur de rendu, dans le processus changeant subtilement comment <table>s se comporter, et donc casser les cas où il a été précédemment mal utilisé.

Et alors? Est-ce que mon patron s'en soucie? Est-ce que mes utilisateurs s'en soucient?

Dépend. Votre patron est-il pointu? Alors il pourrait ne pas s'en soucier. Si elle est compétente, alors elle s'en souciera, car les utilisateurs volonté.

Peut-être moi ou mes collègues développeurs qui doivent entretenir une page web ... Une table est-elle moins facile à entretenir? Je pense que l'utilisation d'une table est plus facile que d'utiliser divs et CSS.

La majorité des développeurs web professionnels semblent s'opposer à vous[citation requise]. Que les tables sont en fait moins maintenable devrait être évident. L'utilisation de tableaux pour la mise en page signifie que changer la mise en page de l'entreprise signifie en fait changer chaque page. Cela peut être très coûteux. D'autre part, l'utilisation judicieuse de HTML sémantiquement significatif combiné avec CSS pourrait limiter ces modifications au CSS et aux images utilisées.

Au fait ... pourquoi utiliser un div ou un span une bonne séparation du contenu de la mise en page et une table non? Obtenir une bonne mise en page avec seulement des divs nécessite souvent beaucoup de divs imbriqués.

Profondément imbriqué <div>s sont un anti-pattern tout comme les mises en page de table. Les bons concepteurs de sites Web n'ont pas besoin de beaucoup d'entre eux. D'un autre côté, même ces divs imbriqués profondément n'ont pas beaucoup de problèmes de disposition de table. En fait, ils peuvent même contribuer à une structure sémantique en divisant logiquement le contenu en parties.

Lisibilité du code   Je pense que c'est l'inverse. La plupart des gens comprennent html, peu comprendre css. C'est plus simple.

"La plupart des gens" n'a pas d'importance. Les professionnels comptent. Pour les professionnels, les mises en page créent beaucoup plus de problèmes que HTML + CSS. C'est comme dire que je ne devrais pas utiliser GVim ou Emacs parce que le bloc-notes est plus simple pour la plupart des gens. Ou que je ne devrais pas utiliser LaTeX parce que MS Word est plus simple pour la plupart des gens.

Il est préférable pour le référencement de ne pas utiliser les tables

Je ne sais pas si c'est vrai et je n'utiliserais pas cela comme argument, mais ce serait logique. Recherche de moteurs de recherche pertinent Les données. Bien que les données tabulaires puissent bien sûr être pertinentes, c'est rarement ce que recherchent les utilisateurs. Les utilisateurs recherchent des termes utilisés dans le titre de la page ou des positions similaires. Il serait donc logique d'exclure le contenu tabulaire du filtrage et de réduire ainsi le temps de traitement (et les coûts!) D'un facteur important.

Les tables sont plus lentes.   Un élément tbody supplémentaire doit être inséré. Ceci est des arachides pour les navigateurs Web modernes.

L'élément supplémentaire n'a rien à voir avec les tables qui sont plus lentes. D'autre part, l'algorithme de disposition des tables est beaucoup plus difficile, le navigateur doit souvent attendre que la table entière se charge avant de pouvoir commencer à mettre en page le contenu. De plus, la mise en cache de la mise en page ne fonctionnera pas (CSS peut facilement être mis en cache). Tout cela a déjà été mentionné.

Montrez-moi quelques repères où l'utilisation d'une table ralentit considérablement une page.

Malheureusement, je n'ai pas de données de référence. Je m'y intéresserais moi-même car il est juste que cet argument manque d'une certaine rigueur scientifique.

La plupart des sites Web qui nécessitent une mise à niveau ont également besoin d'un nouveau contenu (html). Les scénarios où une nouvelle version d'un site Web a seulement besoin d'un nouveau fichier CSS sont peu probables.

Pas du tout. J'ai travaillé sur plusieurs cas où la modification du design a été simplifiée par une séparation du contenu et du design. Il est souvent encore nécessaire de changer du code HTML, mais les changements seront toujours beaucoup plus limités. De plus, les modifications de conception doivent parfois être faites dynamiquement. Envisager des moteurs de gabarit tels que celui utilisé par le système de blogging WordPress. Les dispositions de table tueraient littéralement ce système. J'ai travaillé sur un cas similaire pour un logiciel commercial. Pouvoir modifier la conception sans changer le code HTML était l'une des exigences de l'entreprise.

Autre chose. La disposition de table rend l'analyse automatisée des sites Web (grattage d'écran) beaucoup plus dure. Cela peut sembler trivial parce que, après tout, qui le fait? J'ai été surpris moi-même. Le scraping d'écran peut être très utile si le service en question n'offre pas une alternative WebService pour accéder à ses données. Je travaille en bioinformatique où c'est une triste réalité. Les techniques web modernes et WebServices n'ont pas atteint la plupart des développeurs et souvent, le scraping d'écran est le seul moyen d'automatiser le processus d'obtention de données. Pas étonnant que de nombreux biologistes effectuent encore de telles tâches manuellement. Pour des milliers d'ensembles de données.


497



Voici mon la réponse du programmeur de fil simliar

Sémantique 101

Jetez d'abord un coup d'oeil à ce code et pensez à ce qui ne va pas ici ...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

Le problème, bien sûr, c'est qu'un vélo n'est pas une voiture. La classe de voiture est une classe inappropriée pour l'instance de vélo. Le code est sans erreur, mais est sémantiquement Incorrect. Cela reflète mal sur le programmeur.

Sémantique 102

Appliquez maintenant ceci au balisage de document. Si votre document doit présenter des données tabulaires, la balise appropriée <table>. Cependant, si vous placez la navigation dans un tableau, vous utilisez abusivement le but recherché <table> élément. Dans le second cas, vous ne présentez pas de données tabulaires - vous (utilisez) <table> élément pour atteindre un objectif de présentation.

Conclusion

Les visiteurs remarqueront-ils? Non. Votre patron s'en soucie-t-il? Peut être. Avons-nous parfois des raccourcis en tant que programmeurs? Sûr. Mais devrions-nous? Non. Qui profite si vous utilisez un balisage sémantique? Vous - et votre réputation professionnelle. Maintenant, allez faire la bonne chose.


290



Réponse évidente: Voir CSS Zen Garden. Si vous me dites que vous pouvez facilement faire la même chose avec une mise en page basée sur la table (rappelez-vous - le HTML ne change pas), alors utilisez des tableaux pour la mise en page.

Deux autres choses importantes sont l'accessibilité et le référencement.

Les deux se soucient de l'ordre dans lequel l'information est présentée. Vous ne pouvez pas facilement présenter votre navigation en haut de la page si votre mise en page basée sur des tableaux la place dans la troisième cellule de la deuxième rangée du deuxième tableau imbriqué sur la page.

Vos réponses sont donc la maintenabilité, l'accessibilité et le référencement.

Ne sois pas paresseux. Faites les choses de la bonne façon, même si elles sont un peu plus difficiles à apprendre.


104



Voir cette question en double. 

Un élément que vous oubliez il y a l'accessibilité. Les mises en page basées sur des tableaux ne se traduisent pas aussi bien si vous avez besoin d'un lecteur d'écran, par exemple. Et si vous travaillez pour le gouvernement, soutenir les navigateurs accessibles comme les lecteurs d'écran peut être Champs obligatoires.

Je pense aussi que vous sous-estimez l'impact de certaines des choses que vous avez mentionnées dans la question. Par exemple, si vous êtes à la fois le concepteur et le programmeur, vous pouvez ne pas avoir une idée complète de la façon dont il sépare la présentation du contenu. Mais une fois que vous entrez dans un magasin où ils sont deux rôles distincts, les avantages commencent à devenir plus clairs.

Si vous savez ce que vous faites et si vous avez de bons outils, les CSS ont vraiment des avantages significatifs par rapport aux tableaux de mise en page. Et bien que chaque article en lui-même ne justifie pas l'abandon de tables, cela vaut généralement la peine d'être pris ensemble.


91



Malheureusement, CSS Zen Garden ne peut plus être utilisé comme un exemple de bonne conception HTML / CSS. Pratiquement toutes leurs conceptions récentes utilisent des graphiques pour le titre de section. Ces fichiers graphiques sont spécifiés dans le CSS.

Par conséquent, un site Web dont le but est de montrer l'avantage de garder la conception hors du contenu, maintenant commet régulièrement le NAS IMPOSABLE de mettre du contenu dans la conception. (Si l'en-tête de section dans le fichier HTML devait changer, l'en-tête de section affiché ne le serait pas).

Ce qui ne fait que montrer que même ceux qui préconisent la stricte religion DIV & CSS, ne peuvent pas suivre leurs propres règles. Vous pouvez l'utiliser comme un guide dans la façon dont vous les suivez de près.


54



Ce n'est pas l'argument définitif, en aucun cas, mais avec CSS, vous pouvez prendre le même balisage et modifier la mise en page en fonction du support, ce qui est un bel avantage. Pour une page d'impression, vous pouvez supprimer discrètement la navigation sans avoir à créer une page imprimable, par exemple.


48



Une table pour la mise en page ne serait pas si mauvaise. Mais vous ne pouvez pas obtenir la disposition dont vous avez besoin avec une seule table la plupart du temps. Assez vite, vous avez deux ou trois tables imbriquées. Cela devient très lourd.

  • Il est BEAUCOUP plus difficile à lire. Ce n'est pas à l'opinion. Il y a juste plus de balises imbriquées sans marque d'identification.

  • Séparer le contenu de la présentation est une bonne chose car cela vous permet de vous concentrer sur ce que vous faites. Mélanger les deux mène à des pages gonflées qui sont difficiles à lire.

  • CSS pour les styles permet à votre navigateur de mettre en cache les fichiers et les demandes suivantes sont beaucoup plus rapides. C'est énorme.

  • Les tables vous verrouillent dans un design. Bien sûr, tout le monde n'a pas besoin de la flexibilité de CSS Zen Garden, mais je n'ai jamais travaillé sur un site où je n'avais pas besoin de changer le design un peu ici et là. C'est beaucoup plus facile avec CSS.

  • Les tables sont difficiles à coiffer. Vous n'avez pas beaucoup de flexibilité avec eux (c'est-à-dire que vous devez toujours ajouter des attributs HTML pour contrôler entièrement les styles d'une table)

Je n'ai pas utilisé de tables pour les données non tabulaires dans probablement 4 ans. Je n'ai pas regardé en arrière.

Je voudrais vraiment suggérer de lire Maîtrise CSS par Andy Budd. C'est fantastique.

Image sur ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg


45



Il est bon de séparer le contenu de la mise en page
  Mais c'est un argument fallacieux; Cliché Pensée

C'est un argument fallacieux parce que les tableaux HTML sont mis en page! Le contenu est le Les données dans la table, la présentation est la table elle-même. C'est pourquoi séparer CSS de HTML peut être très difficile à la fois. Vous ne séparez pas le contenu de la présentation, vous séparez la présentation de la présentation! Une pile de divs imbriqués n'est pas différente d'une table - c'est juste un ensemble différent de tags.

L'autre problème avec la séparation du HTML du CSS est qu'ils ont besoin d'une connaissance intime les uns des autres - vous ne pouvez vraiment pas les séparer complètement. La disposition des tags dans le HTML est étroitement liée au fichier CSS, peu importe ce que vous faites.

Je pense que les tableaux vs divs correspondent aux besoins de votre application.

Dans l'application que nous développons au travail, nous avions besoin d'une mise en page où les pièces se dimensionneraient dynamiquement à leur contenu. J'ai passé des jours à essayer de faire fonctionner ceci cross-browser avec CSS et DIVs et c'était un cauchemar complet. Nous sommes passés aux tables et tout juste travaillé.

Cependant, nous avons un public très fermé pour notre produit (nous vendons un morceau de matériel avec une interface web) et les problèmes d'accessibilité ne sont pas une préoccupation pour nous. Je ne sais pas pourquoi les lecteurs d'écran ne peuvent pas bien traiter les tableaux, mais je suppose que si c'est ainsi, les développeurs doivent s'en occuper.


36



CSS / DIV - c'est juste un travail pour les concepteurs, n'est-ce pas? Les centaines d'heures que j'ai consacrées au débogage des problèmes DIV / CSS, la recherche sur Internet pour faire fonctionner une partie du balisage avec un navigateur obscur - ça me rend fou. Vous faites un petit changement et toute la mise en page a horriblement mal - où est la logique dans cela. Passer des heures à déplacer quelque chose de 3 pixels de cette façon, puis quelque chose d'autre 2 pixels l'autre pour les aligner tous. Cela me semble tout simplement faux. Juste parce que vous êtes un puriste et que quelque chose n'est pas la bonne chose à faire ne signifie pas que vous devriez l'utiliser au nième degré et dans toutes les circonstances, surtout si cela vous facilite la vie 1000 fois.

Donc, j'ai finalement décidé, purement pour des raisons commerciales, bien que je continue à utiliser au minimum, si je prévois 20 heures de travail pour obtenir un DIV placé correctement, je vais coller dans une table. C'est faux, cela dérange les puristes, mais dans la plupart des cas, cela coûte moins de temps et coûte moins cher à gérer. Je peux alors me concentrer à faire fonctionner l'application comme le souhaite le client, plutôt que de plaire aux puristes. Ils payent les factures après tout et mon argumentation à un gestionnaire appliquant l'utilisation de CSS / DIV - Je voudrais simplement souligner que les clients paient aussi son salaire!

La seule raison pour laquelle tous ces arguments CSS / DIV se produisent est en raison de la lacune de CSS en premier lieu et parce que les navigateurs ne sont pas compatibles entre eux et si ils l'étaient, la moitié des concepteurs de sites Web dans le monde seraient sans emploi .

Lorsque vous concevez un formulaire Windows, vous n'essayez pas de déplacer les contrôles une fois que vous les avez disposés, donc je pense que c'est étrange pour moi pourquoi vous voudriez le faire avec un formulaire web. Je ne peux tout simplement pas comprendre cette logique. Obtenez la bonne mise en page pour commencer et quel est le problème. Je pense que c'est parce que les concepteurs aiment flirter avec la créativité, tandis que les développeurs d'applications cherchent plutôt à faire fonctionner l'application, à créer des objets métier, à mettre en œuvre des règles métier, à établir des liens entre les données clients exigences - vous le savez - comme les choses du monde réel.

Ne vous méprenez pas, les deux arguments sont valables, mais s'il vous plaît ne critiquez pas les développeurs pour avoir choisi une approche plus simple et plus logique pour concevoir des formulaires. Nous avons souvent des choses plus importantes à s'inquiéter que la sémantique correcte de l'utilisation d'une table sur un div.

Exemple de cas - basé sur cette discussion, j'ai converti quelques tds et très existants en divs. 45 minutes de déconner avec essayer d'obtenir tout à aligner les uns à côté des autres et j'ai abandonné. TDs de retour dans 10 secondes plus tard - fonctionne - tout de suite - sur tous les navigateurs, rien de plus à faire. S'il vous plaît, essayez de me faire comprendre - quelle justification avez-vous de vouloir que je le fasse autrement?


23