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

665

Il semble être l' opinion générale que les tableaux ne devraient pas être utilisés 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:

  • Il est bon de séparer le contenu de la mise en page.
    Mais c'est un argument fallacieux; Pensée de cliché . Je suppose qu'il 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? Mon patron s'en soucie-t-il? Mes utilisateurs s'en soucient-ils?

    Peut-être moi ou mes collègues développeurs qui doivent entretenir une page Web ... Un tableau est-il moins maintenable? Je pense qu'il est plus facile d' utiliser une table que d'utiliser des divs et CSS.

    Au fait ... pourquoi l'utilisation d'une div ou d'une span permet-elle de bien séparer le contenu de la mise en page et un tableau 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 le HTML, peu comprennent le CSS.

  • Il est préférable pour le SEO de ne pas utiliser de tableaux
    Pourquoi? Quelqu'un peut-il prouver que c'est le cas? Ou une déclaration de Google selon laquelle les tableaux sont découragés du point de vue du référencement?

  • Les tables sont plus lentes.
    Un élément tbody supplémentaire doit être inséré. Il s'agit d'arachides pour les navigateurs Web modernes. Montrez-moi quelques repères où l'utilisation d'un tableau 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 ont besoin d'une mise à niveau ont également besoin d'un nouveau contenu (HTML). Les scénarios où une nouvelle version d'un site Web n'a besoin que d'un nouveau fichier CSS sont peu probables. Zen Garden est un joli site web, mais un peu théorique. Sans parler de son utilisation abusive de CSS.

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

Benno Richters
la source
D'accord, les tableaux conviennent bien lors de la présentation de données tabulaires. Ils doivent être évités lorsque vous l'utilisez uniquement pour la mise en page. Là encore, parfois, vous devez prendre la route facile maintenant et l'améliorer plus tard. Il suffit de voir la source et vous verrez ce que je veux dire.
hacké le
Il y a des questions et réponses en double sur stackoverflow.com/questions/30251/tables-instead-of-divs
Onorio Catenacci
11
La réponse est simple: cela dépend. Si les tables sont utilisées pour résoudre un problème spécifique que les versions CSS actuelles ne peuvent pas, elles sont bien utilisées. Si vous commencez à placer des tables dans des tables, à l'intérieur de millions de tables, vous vous trompez. Si c'est la table occasionnelle juste pour mettre en page 2 colonnes ou quelque chose comme ça, je ne l'interdit pas à mon équipe: c'est plus rapide et plus facile à faire. (Moi-même, j'essaie toujours d'utiliser CSS, mais à la fin de la journée, la livraison est plus importante que le HTML sémantique correct)
AlfaTeK
1
@Camilo SO vit toujours au 20e siècle. Jeff ne sait apparemment pas comment utiliser la ulbalise. Jetez un œil à toutes les listes de ce site (badges, questions connexes, tags récents). Ce sont tous des colonnes simples ou de longs paragraphes séparés par br.
Yi Jiang
2
@Brad: En fonction de certains détails spécifiques (c'est ma sortie pour tout retour intelligent ;-) que l'utilisation des DIVs est TOUJOURS mieux que d'abuser des tables. Deux parties d'un document qui se trouvent côte à côte peuvent légitimement être contenues dans des éléments DIV, mais ce ne sont certainement PAS des données tabulaires. Peu importe quel style spécifique se trouve être; le contenu est tabulaire ou non. Remarque: je ne préconise PAS DIVitis non plus :)
Bobby Jack

Réponses:

496

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

C'est bien de séparer le contenu de la mise en page. Mais c'est un argument fallacieux; Pensée de cliché.

Ce n'est pas fallacieux du tout parce que HTML a été conçu intentionnellement. L'utilisation abusive d'un élément n'est peut-être pas complètement hors de question (après tout, de nouveaux idiomes se sont également développés dans d'autres langues), mais les éventuelles implications négatives doivent être contrebalancées. De plus, même s'il n'y avait aucun argument contre une mauvaise utilisation de l' <table>élément aujourd'hui, il pourrait y en avoir demain en raison de la façon dont les fournisseurs de navigateurs appliquent un traitement spécial à l'élément. Après tout, ils savent que «les <table>éléments ne concernent que les données tabulaires» et pourraient utiliser ce fait pour améliorer le moteur de rendu, modifiant ainsi subtilement le <table>comportement, et ainsi rompre les cas où il était précédemment mal utilisé.

Et alors? Mon patron s'en soucie-t-il? Mes utilisateurs s'en soucient-ils?

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

Peut-être moi ou mes collègues développeurs qui doivent entretenir une page Web ... Un tableau est-il moins maintenable? Je pense qu'il est plus facile d'utiliser une table que d'utiliser des divs et css.

La majorité des développeurs Web professionnels semblent vous opposer[ citation nécessaire ] . Que les tableaux soient en fait moins faciles à gérer 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'un autre côté, une utilisation judicieuse de HTML sémantiquement significatif combiné à CSS pourrait limiter ces modifications au CSS et aux images utilisées.

Au fait ... pourquoi l'utilisation d'une div ou d'une span permet-elle de bien séparer le 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.

Les <div>s profondément imbriqués sont un anti-modèle tout comme les dispositions de table. Les bons concepteurs de sites Web n'en ont pas besoin de beaucoup. D'un autre côté, même de telles divisions profondément imbriquées n'ont pas beaucoup de problèmes de mise en page 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 le HTML, peu le CSS. C'est plus simple.

«La plupart des gens» n'ont pas d'importance. Les professionnels comptent. Pour les professionnels, les dispositions de table créent beaucoup plus de problèmes que HTML + CSS. C'est comme dire que je ne devrais pas utiliser GVim ou Emacs car 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 SEO de ne pas utiliser de tableaux

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

Les tables sont plus lentes. Un élément tbody supplémentaire doit être inséré. Il s'agit d'arachides pour les navigateurs Web modernes.

L'élément supplémentaire n'a rien à voir avec le ralentissement des tables. D'un autre côté, l'algorithme de mise en page pour les tableaux 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'un tableau ralentit considérablement une page.

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

La plupart des sites Web qui ont besoin d'une mise à niveau ont également besoin d'un nouveau contenu (html). Les scénarios où une nouvelle version d'un site Web n'a besoin que 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 apportées de manière dynamique. Envisagez des moteurs de modèles tels que celui utilisé par le système de blog WordPress. Les dispositions de table tueraient littéralement ce système. J'ai travaillé sur un cas similaire pour un logiciel commercial. Pouvoir changer la conception sans changer le code HTML était l'une des exigences de l'entreprise.

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

Konrad Rudolph
la source
139
"changer la présentation de l'entreprise signifie en fait changer chaque page" - Les gens reproduisent-ils toujours la présentation de l'entreprise sur chaque page? C'est si facile à résoudre avec des pages maîtres ou des contrôles utilisateur en .net, inclure des fichiers en php ou en asp classique, etc ... Quiconque copie la mise en page de l'entreprise comme ça mérite un ** coup de pied! ;-)
John MacIntyre
43
Désolé, mais c'est vraiment un vœu pieux dans le ciel. Les utilisateurs se soucient? Non. Personne ne s'en soucie, sauf un petit nombre de révisionnistes malavisés. HTML (y compris les tableaux) est bien plus ancien que la notion relativement nouvelle de "sémantique vs mise en page". Oh et source s'il vous plaît pour "la majorité des développeurs web professionnels vous opposent".
cletus
20
Typo ci-dessus: la sémantique était implicite depuis le début. <table> en HTML était toujours uniquement destiné aux données tabulaires, jamais à la mise en page (au début, vous ne pouviez pas changer l'apparence du tableau de toute façon, empêchant ainsi son utilisation comme ancre de mise en page). En fait, les premières ébauches de HTML n'avaient aucune notion de mise en page et le HTML n'était jamais destiné à la mise en page, mais à la structuration du texte. Encore plus: la toute première proposition de HTML met en garde à plusieurs reprises contre l'utilisation abusive des balises pour influencer la mise en page et met en garde contre l'utilisation d'un balisage logique plutôt que physique.
Konrad Rudolph
109
Procurez-vous un lecteur d'écran et faites-le lire une page avec une disposition de tableau. c'est tout.
corymathews le
8
@Sergio: veuillez ne pas modifier les informations pertinentes. Il s'agit d' une allégation douteuse non source que j'utilise là-bas et je tiens à le dire très clairement. Votre montage m'a mis dans la bouche que je ne pouvais pas sauvegarder, ce qui fait de moi un menteur si cela s'avérait faux.
Konrad Rudolph
290

Voici la réponse de mon programmeur à partir d'un fil similaire

Sémantique 101

Jetez d'abord un œil à ce code et réfléchissez à 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 le programmeur.

Sémantique 102

Appliquez maintenant ceci au balisage de document. Si votre document doit présenter des données tabulaires, alors la balise appropriée serait <table>. Cependant, si vous placez la navigation dans un tableau, vous abusez du but prévu de l' <table>élément. Dans le second cas, vous ne présentez pas de données tabulaires - vous utilisez (mal) l' <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 en profite si vous utilisez le balisage sémantique? Vous - et votre réputation professionnelle. Maintenant, allez faire la bonne chose.

Appareil photo Carl
la source
39
Désolé, cela ne tient pas la route. Vous n'utilisez pas la voiture pour mybike car vous définiriez plutôt une classe "vélo". Vous ne pouvez pas définir autre chose pour "<table>" car c'est plus qu'une simple balise sémantique - elle indique également au navigateur comment afficher son contenu.
Jimmy
57
Belle analogie et bonne conclusion. Pourquoi quelqu'un devrait-il être contraint par son patron et / ou ses utilisateurs à faire la bonne chose? Personne n'est plus fier de son propre travail?
Sherm Pendley
39
Je pense que c'est un article assez arrogant qui n'explique rien mais répète simplement les mêmes affirmations sans répondre à la question. Je ne comprends pas pourquoi il y a eu tant de votes positifs ????
Markus
10
Je suis d'accord avec tharkum. Cette réponse est plutôt subjective et ne répond pas réellement à la question posée. Bien que je convienne que les DIV doivent être utilisés pour la mise en page, je ne peux pas imaginer qu'un concepteur Web serait confus par une mise en page basée sur une table.
Richard Ev
16
@tharkun & Richard: Comment se fait-il que "sémantiquement incorrect" soit subjectif et n'explique rien?
Vinko Vrsalovic
104

Réponse évidente: voir CSS Zen Garden . Si vous me dites que vous pouvez facilement faire de même avec une mise en page basée sur des tableaux (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 les informations sont présentées. Vous ne pouvez pas facilement présenter votre navigation en haut de la page si votre disposition basée sur un tableau la place dans la 3e cellule de la 2e ligne du 2e 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 correctement et correctement, même si elles sont un peu plus difficiles à apprendre.

erlando
la source
24
Une astuce souvent utilisée dans Zen Garden consiste à remplacer le texte par des images et à le définir dans le CSS, le rendant ainsi invisible à partir du HTML. Très, très mal.
GvS
3
Je suis désolé mais ce n'est pas vrai. Le texte est toujours au format HTML - c'est l'une des exigences d'une conception CSSZG. Le HTML doit rester inchangé.
erlando
10
Si vous examinez de près certains des modèles, le texte de certains en-têtes est différent du texte HTML. C'est parce que le HTML est rendu invisible, et à la place une image est insérée. (Exemple: csszengarden.com/?cssfile=/212/212.css&page=0 , The? Path? To ? Achievement?)
GvS
6
Désolé, il n'y a absolument aucune preuve que les dispositions div sont meilleures pour le référencement. De plus, Google eux-mêmes ont déclaré que la validation HTML ne leur importait pas - un problème légèrement différent, mais qui visait les tableaux car ils valident rarement.
DisgruntledGoat
«La plupart d'entre vous connaissent les vertus d'un programmeur. Il y en a bien sûr trois: la paresse, l'impatience et l'orgueil. » - Larry Wall
inkredibl
91

Voir cette question en double.

Un élément que vous oubliez est l'accessibilité. Les dispositions basées sur des tableaux ne se traduisent pas aussi bien si vous devez utiliser un lecteur d'écran, par exemple. Et si vous travaillez pour le gouvernement, il peut être nécessaire de prendre en charge des navigateurs accessibles tels que des lecteurs d'écran .

Je pense également 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, il se peut que vous ne compreniez pas à quel point il sépare la présentation du contenu. Mais une fois que vous entrez dans un magasin où il s'agit de deux rôles distincts, les avantages commencent à devenir plus clairs.

Si vous savez ce que vous faites et que vous avez de bons outils, CSS a vraiment des avantages significatifs par rapport aux tableaux de mise en page. Et bien que chaque élément ne justifie pas à lui seul l'abandon des tables, pris ensemble, cela en vaut généralement la peine.

Joel Coehoorn
la source
Oui en effet. Je vois que c'est en double. Je l'ai raté. Toute action requise en plus de la promesse, je serai plus prudente la prochaine fois :-)?
Benno Richters
Ne t'inquiète pas. Ce sera de plus en plus courant à mesure que le nombre de questions augmente. Je n'ai même pas downvote. Nous voulons juste être sûrs que, dans la mesure du possible, ils finissent tous par pointer vers une source commune.
Joel Coehoorn
8
J'aime vraiment cette réponse. L'utilisation de balises sémantiquement significatives n'est pas seulement une question de tradition, elle permet à ces non-navigateurs obscurs (lecteurs d'écran, grattoirs d'écran, divers analyseurs) de classer correctement les divers objets sur votre page.
Phantom Watson
6
J'espérais que quelqu'un en parlerait. L'accessibilité devrait être une priorité absolue!
Andrew
Je ne peux pas dire que je suis d'accord avec l'idée que l'accessibilité devrait être une priorité absolue dans un exercice commercial. Le rapport coûts-avantages n'est pas réalisable. C'est comme mettre une rampe pour fauteuil roulant sur un magasin d'alpinisme - un gaspillage ridicule de ressources qui pourrait être appliqué à des articles avec un meilleur CBR. Si vous parliez d'un établissement médical, une rampe pour fauteuil roulant serait une priorité. De même, je ne me soucierais que de l'accessibilité des pages Web pour les sites destinés aux personnes malvoyantes.
Peter Wone
54

Malheureusement, CSS Zen Garden ne peut plus être utilisé comme exemple de bonne conception HTML / CSS. Presque toutes leurs conceptions récentes utilisent des graphiques pour l'en-tête 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 le design hors du contenu, engage désormais régulièrement le NAS INSPEAKABLE de mettre du contenu dans le design. (Si l'en-tête de section du 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 vous en servir comme guide pour savoir dans quelle mesure vous les suivez.

James Curran
la source
18
Vous voulez dire qu'ils font <h1>Some Text</h1>et dans leur css: h1 { background-image('foo.jpg'); text-indent:-3000px }? C'est la bonne façon de procéder, car vous conservez un maximum d'informations sémantiques dans le HTML sans style. Ou peut-être que je vous ai mal compris.
Karan
9
Karen a raison, tu as tort, James. Votre exemple est un homme de paille. Pour oublier de changer l'image lorsque vous avez changé le HTML sémantique serait stupide. Il en va de même pour votre ordinateur portable dans un bus. À quoi veux-tu en venir?
AmbroseChapel
36
@Ambrose: Parce que tout l'intérêt du site friggin 'est de démontrer la séparation du contenu et du style. Le contenu et le style doivent être correctement gérés par différentes personnes, qui ne doivent ni se «rappeler» ce que l'autre a changé.
James Curran
5
Mr S&N: cela aggraverait les choses. Vous devrez générer dynamiquement de nouvelles images - dans le bon style. Alors maintenant, vous avez déplacé le style de CSS vers le code de couche métier.
James Curran
9
@James: le contenu et le style ne peuvent pas toujours être gérés par des personnes différentes. Lorsque le contenu est stylisé, la collaboration doit avoir lieu. Comment est-il <h1><img src="something.png"></h1>plus maintenable que <h1 class="something image">Something</h1>? Dans les deux exemples, something.png doit être mis à jour. Mais le deuxième exemple est beaucoup plus accessible.
Josh
48

Ce n'est en aucun cas l'argument définitif, 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 tranquillement la navigation sans avoir à créer une page imprimable, par exemple.

opportun
la source
Bon point, bien que vous puissiez utiliser css pour masquer les cellules dans une disposition basée sur un tableau, pour supprimer la navigation dans une version imprimable par exemple, une disposition CSS vous donne beaucoup plus de flexibilité derrière le simple fait de masquer des données.
Cory House
J'ai frappé ceci avec une de mes applications; mon garçon était heureux quand j'ai réalisé à quel point il était facile de créer la version "imprimable" avec juste quelques CSS imprimés pour les mêmes pages que celles à l'écran.
Lawrence Dol
45

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. Très vite, vous avez 2 ou 3 tables imbriquées. Cela devient très lourd.

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

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

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

  • Les tables vous enferment 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 un peu la conception ici et là. C'est beaucoup plus facile avec CSS.

  • Les tableaux 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 pleinement les styles d'un tableau)

Je n'ai pas utilisé de tableaux pour des données non tabulaires depuis probablement 4 ans. Je n'ai pas regardé en arrière.

J'aimerais vraiment suggérer de lire CSS Mastery 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

Ben Scheirman
la source
1
Je peux fortement recommander ce livre
Jacob T. Nielsen
Contient de bons exemples pour le modèle de boîte, les sélecteurs et le positionnement.
KMån
36

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

C'est un argument fallacieux car les tableaux HTML sont de mise en page! Le contenu est les données du tableau, la présentation est le tableau lui-même. C'est pourquoi la séparation du CSS du HTML peut parfois être très difficile. Vous ne séparez pas le contenu de la présentation, vous séparez la présentation de la présentation! Un tas de divs imbriqués n'est pas différent d'une table - c'est juste un ensemble différent de balises.

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 balises dans le HTML est étroitement associée au fichier CSS, peu importe ce que vous faites.

Je pense que tables vs divs se résume 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 cela sur plusieurs navigateurs avec CSS et DIV et ce fut un cauchemar complet. Nous sommes passés à des tables et tout a fonctionné .

Cependant, nous avons un public très fermé pour notre produit (nous vendons un matériel avec une interface Web) et les problèmes d'accessibilité ne nous préoccupent pas. Je ne sais pas pourquoi les lecteurs d'écran ne peuvent pas bien gérer les tableaux, mais je suppose que si c'est ainsi, les développeurs doivent le gérer.

17 sur 26
la source
6
les lecteurs d'écran traitent les tableaux ok. C'est la façon dont les tableaux ne traitent pas avec les lecteurs d'écran qui pose problème. Une disposition sous forme de tableau est susceptible de présenter les informations de manière inaccessible. Pensez à quoi ressemblerait une navigation à droite. Ce serait assez loin sur la page.
erlando
Ok, ça a du sens alors - merci!
17 de 26
8
Tout simplement parce que <table> ou <div> ont une présentation par défaut dans la plupart des agents d'écran, ne les assimile pas à des éléments de présentation au lieu d'éléments sémantiques.
Mark Brackett
1
Je ne parle pas spécifiquement de HTML, je parle de manière conceptuelle dans la conception d'interface utilisateur de base. Un tableau dicte la façon dont les choses sont présentées à l'écran, c'est-à-dire comment elles sont présentées à l'utilisateur. Voilà la présentation.
17 de 26
1
"J'ai passé des jours à essayer de le faire fonctionner" - si quelque chose que j'essaie de comprendre prend plus de quelques heures, je le soumets à la communauté StackOverflow. Ne pas savoir comment faire quelque chose correctement n'est pas une excuse pour ne pas le faire correctement. Surtout quand nous avons toutes les réponses à portée de main.
DaveDev
23

CSS / DIV - ce ne sont que des emplois pour les concepteurs, n'est-ce pas. Les centaines d'heures que j'ai passées à déboguer des problèmes DIV / CSS, à chercher sur Internet pour faire fonctionner une partie du balisage avec un navigateur obscur - cela me rend fou. Vous apportez un petit changement et toute la mise en page va terriblement mal - où en est la logique là-dedans. Passer des heures à déplacer quelque chose de 3 pixels de cette façon puis quelque chose d'autre à 2 pixels de l'autre pour les aligner. Cela me semble tout simplement faux. Ce n'est pas parce que vous êtes un puriste et que quelque chose n'est "pas la bonne chose à faire" que vous devez l'utiliser au nième degré et en toutes circonstances, surtout si cela vous facilite la vie 1000 fois.

J'ai donc finalement décidé, uniquement pour des raisons commerciales, bien que j'en garde au minimum, si je prévois 20 heures de travail pour placer correctement un DIV, je vais rester dans une table. C'est faux, ça dérange les puristes, mais dans la plupart des cas ça coûte moins de temps et c'est moins cher à gérer. Je peux alors me concentrer sur le fonctionnement de l'application comme le souhaite le client, plutôt que de plaire aux puristes. Ils paient les factures après tout et mon argument à un gestionnaire imposant l'utilisation de CSS / DIV - je voudrais simplement signaler que les clients paient également son salaire!

La seule raison pour laquelle tous ces arguments CSS / DIV se produisent est à cause de l'insuffisance de CSS en premier lieu et parce que les navigateurs ne sont pas compatibles entre eux et s'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 après les avoir disposés, donc je pense que c'est étrange pour moi pourquoi vous souhaitez faire cela avec un formulaire Web. Je ne comprends tout simplement pas 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 sont plus soucieux de faire fonctionner l'application, de créer des objets métier, de mettre en œuvre des règles métier, de déterminer comment les bits de données client sont liés les uns aux autres, de s'assurer que la chose rencontre les clients exigences - vous savez - comme les trucs du monde réel.

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

Cas d'espèce - sur la base de cette discussion, j'ai converti quelques tds et très existants en divs. 45 minutes à jouer avec ça en essayant de tout aligner les uns à côté des autres et j'ai abandonné. Les TD reviennent 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 pour vouloir que je le fasse autrement!

Peter Mortensen
la source
Je ne pourrais être plus d'accord avec ce post. Au cours des 10 années que j'ai passées dans la conception, je ne peux pas penser à une seule fois où l'argument "nous utilisons CSS parce qu'il facilite les modifications à l'échelle du site" s'est avéré aussi précis.
Daniel Szabo
6
savez-vous ce qui rend les modifications à l'échelle du site faciles à gérer? MVC et systèmes de modèles
Jiaaro
S'il vous plaît, ne vous méprenez pas - j'utilise toujours CSS mais je l'utilise pour appliquer le style (couleur, images d'arrière-plan, etc.) et non la mise en page. CSS semble être à peu près cohérent entre les navigateurs lorsqu'il est utilisé pour contrôler le style uniquement. Là où il est imparfait et tombe en grande partie, c'est la façon dont la mise en page est à la fois spécifiée et mise en œuvre sur tous les navigateurs. Quelqu'un a-t-il déjà essayé de faire en sorte que les MasterPages ASP.NET fonctionnent de manière fiable avec les DIV? C'est presque impossible!
Tim Black
21

La mise en page doit être simple. Le fait qu'il existe des articles écrits sur la façon de réaliser une mise en page dynamique à trois colonnes avec en-tête et pied de page en CSS montre qu'il s'agit d'un système de mise en page médiocre. Bien sûr, vous pouvez le faire fonctionner, mais il existe littéralement des centaines d'articles en ligne sur la façon de le faire. Il n'y a pratiquement pas d'articles de ce type pour une mise en page similaire avec des tableaux, car c'est clairement évident. Peu importe ce que vous dites contre les tableaux et en faveur de CSS, celui-ci annule tout: une disposition de base à trois colonnes en CSS est souvent appelée "Le Saint Graal".

Si cela ne vous fait pas dire "WTF", alors vous devez vraiment déposer le kool-aid maintenant.

J'adore CSS. Il offre des options de style incroyables et des outils de positionnement sympas, mais en tant que moteur de mise en page, il est déficient. Il doit y avoir un certain type de système de positionnement de grille dynamique. Un moyen simple d'aligner les boîtes sur plusieurs axes sans connaître d'abord leur taille. Je m'en fous si vous l'appelez <table> ou <gridlayout> ou peu importe, mais c'est une fonctionnalité de mise en page de base qui manque dans CSS.

Le plus gros problème est qu'en n'admettant pas qu'il manque des fonctionnalités, les fanatiques CSS ont retenu CSS de tout ce qu'il pourrait être. Je serais parfaitement heureux d'arrêter d'utiliser des tableaux si CSS fournissait un positionnement de grille multi-axes décent comme pratiquement tous les autres moteurs de mise en page dans le monde. (Vous vous rendez compte que ce problème a déjà été résolu plusieurs fois dans de nombreuses langues par tout le monde sauf le W3C, n'est-ce pas? Et personne d'autre n'a nié qu'une telle fonctionnalité était utile.)

Soupir. Assez d'aération. Allez-y et collez votre tête en arrière dans le sable.

pile d'aiguille
la source
Les "fanatiques CSS" (comme vous le dites) ne l'ignorent pas. La prochaine spécification CSS n'a pas seulement une, mais deux solutions pour résoudre les problèmes de mise en page en CSS. Disposition des modèles: w3.org/TR/css3-layout et positionnement de la grille: w3.org/TR/css3-grid Cela n'introduit pas de spécifications concurrentes. Les 2 spécifications se complètent réellement. Au moment de la rédaction de ce commentaire, aucun navigateur ne l'implémentait pour l'instant.
Dan Herbert
+1: Je suis entièrement d'accord. Vous ne devriez pas avoir à "le faire fonctionner" (même si je n'aime pas les tableaux non plus).
3lectrologos
C'est exactement ce que je ressens à 100%. J'aimerais pouvoir vous voter à la première réponse.
bobwienholt
19

Selon la conformité 508 (pour les lecteurs d'écran pour les visuels non conformes), les tableaux ne doivent être utilisés que pour conserver les données et non pour la mise en page car cela fait paniquer les lecteurs d'écran. Du moins, on me l'a dit.

Si vous attribuez des noms à chacune des divs, vous pouvez également les habiller tous ensemble à l'aide de CSS. Ils sont juste un peu plus pénibles pour s'asseoir comme vous en avez besoin.

Rob
la source
18

Voici une section html d'un projet récent:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

Et voici ce même code qu'une disposition basée sur une table.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

La seule propreté que je vois dans cette disposition basée sur un tableau est le fait que je suis trop zélé avec mon indentation. Je suis sûr que la section de contenu aurait deux autres tableaux intégrés.

Une autre chose à penser: la taille des fichiers . J'ai constaté que les mises en page basées sur des tables sont généralement deux fois plus grandes que leurs homologues CSS. Sur notre large bande à haute vitesse, ce n'est pas un gros problème, mais c'est sur ceux avec des modems commutés.

Ross
la source
3
la vitesse n'est pas la seule chose qui est affectée par des fichiers plus volumineux: de nombreuses entreprises paient pour la bande passante. Si vous pouvez réduire de moitié les factures de bande passante de votre client simplement en codant bien, c'est un grand avantage.
M. Shiny et New 安 宇
2
Oui, mais n'oubliez pas que même si le HTML peut être deux fois plus grand dans une mise en page sans CSS, l'utilisation d'une mise en page CSS DIV + entraînera (au moins) une demande HTTP supplémentaire pour le fichier CSS, plus l'utilisation de la bande passante pour le fichier lui-même.
goldenratio
12
Mais le fichier css n'a besoin d'être téléchargé qu'une seule fois, alors que la structure entière du tableau est renvoyée à chaque demande de page.
user151841
3
Vous avez choisi un design bien adapté à div + css et montré qu'il est plus détaillé dans un design basé sur des tableaux? Alors quoi: Il serait tout aussi facile de créer un design bien adapté à une mise en page basée sur des tableaux et de montrer les cerceaux que vous devrez parcourir pour le répliquer en CSS.
Draemon
4
@Draemon: Peut-être aimeriez-vous donner un exemple?
Bobby Jack
14

Je voudrais ajouter que les dispositions basées sur les div sont plus faciles à maintenir, à faire évoluer et à remanier. Juste quelques changements dans le CSS pour réorganiser les éléments et c'est fait. D'après mon expérience, la refonte d'une mise en page qui utilise des tables est un cauchemar (plus s'il y a des tables imbriquées).

Votre code a également une signification d'un point de vue sémantique .

Guido
la source
Mon rêve est d'avoir un graphiste qui prend les objets / données que je fournis et les met dans une page sans que je
Manrico Corazzi
J'appuie Manrico - un concepteur visuel qui vous permettrait de construire une mise en page et de définir des dimensions fixes et en pourcentage, puis de générer un minimum de code HTML et CSS serait extrêmement utile!
Richard Ev
Le problème que j'ai avec le concept de web sémantique est qu'en HTML 4 le vocabulaire est très limité et conçu pour des documents principalement techniques. De nombreux sites ayant des objectifs commerciaux / marketing peuvent avoir des éléments qui ne correspondent pas parfaitement à ce vocabulaire. HTML 5 corrige certains de ces problèmes avec des balises comme nav, header, footer, mais pour l'instant, nous sommes bloqués à l'aide de balises comme span qui ne disent pas grand-chose sur la façon dont le contenu doit être interprété.
Nick Van Brunt,
13

Aucun argument dans DIVs ne me favorise.

Je dirais: si la chaussure vous va, portez-la.

Il convient de noter qu'il est difficile, voire impossible, de trouver une bonne méthode DIV + CSS de rendu de contenu sur deux ou trois colonnes, qui soit cohérente sur tous les navigateurs et qui ressemble toujours à ce que je voulais.

Cela fait pencher la balance un peu vers les tableaux dans la plupart de mes mises en page, et même si je me sens coupable de les utiliser (dunny pourquoi, les gens disent juste que c'est mauvais alors j'essaie de les écouter), à la fin, la vue pragmatique est que c'est juste plus facile et plus rapide pour moi d'utiliser des tables. Je ne suis pas payé à l'heure, donc les tables sont moins chères pour moi.

Radu094
la source
1
si vous souhaitez créer un site Web à deux ou trois colonnes avec divs + css qui fonctionne dans tous les navigateurs, vous ne devez absolument pas recommencer à zéro. Il existe de nombreux modèles barebone disponibles sur le Web que vous pouvez utiliser comme base. Ceux-ci sont généralement optimisés pour s'afficher correctement dans tous les navigateurs ie6 +
arturh
13

Les mises en page CSS sont généralement bien meilleures pour l'accessibilité, à condition que le contenu vienne dans un ordre naturel et soit logique sans feuille de style. Et ce ne sont pas seulement les lecteurs d'écran qui ont du mal avec les dispositions basées sur des tableaux: ils rendent également beaucoup plus difficile pour les navigateurs mobiles de rendre une page correctement.

De plus, avec une mise en page div, vous pouvez très facilement faire des choses sympas avec une feuille de style d'impression, comme exclure les en-têtes, les pieds de page et la navigation des pages imprimées - je pense qu'il serait impossible, ou du moins beaucoup plus difficile, de le faire avec un mise en page sous forme de tableau.

Si vous doutez que la séparation du contenu de la mise en page soit plus facile avec les div qu'avec les tableaux, jetez un œil au HTML basé sur les div au CSS Zen Garden , voyez comment le changement des feuilles de style peut changer radicalement la mise en page et pensez si vous pourriez obtenir la même variété de mises en page si le HTML était basé sur un tableau ... Si vous faites une mise en page basée sur un tableau, il est peu probable que vous utilisiez CSS pour contrôler tout l'espacement et le remplissage dans les cellules (si vous l'étiez, vous trouverais presque certainement plus facile d'utiliser des divs flottants, etc. en premier lieu). Sans utiliser CSS pour contrôler tout cela, et du fait que les tableaux spécifient l'ordre des choses de gauche à droite et de haut en bas dans le HTML, les tableaux ont tendance à signifier que votre mise en page devient très fixe dans le HTML.

De manière réaliste, je pense qu'il est très difficile de changer complètement la disposition d'une conception basée sur div et CSS sans changer un peu les divs. Cependant, avec une mise en page basée sur div et CSS, il est beaucoup plus facile de modifier des choses comme l'espacement entre les différents blocs et leurs tailles relatives.

MB.
la source
13

Le fait qu'il s'agisse d'une question très controversée témoigne de l'échec du W3C à anticiper la diversité des schémas de configuration qui seraient tentés. L'utilisation de divs + css pour une mise en page sémantique conviviale est un excellent concept, mais les détails de la mise en œuvre sont si imparfaits qu'ils limitent en fait la liberté de création.

J'ai tenté de changer l'un des sites de notre entreprise de tables en divs, et c'était un tel casse-tête que j'ai complètement abandonné les heures de travail que j'y avais consacrées et suis retourné aux tables. Essayer de lutter avec mes divs pour prendre le contrôle de l'alignement vertical m'a maudit avec des problèmes psychologiques majeurs que je ne secouerai jamais tant que ce débat fera rage.

Le fait que les gens doivent souvent trouver des solutions de contournement complexes et laides pour atteindre des objectifs de conception simples (tels que l'alignement vertical) suggère fortement que les règles ne sont pas assez flexibles. Si les spécifications SONT suffisantes, alors pourquoi les sites de haut niveau (comme SO) trouvent-ils nécessaire de contourner les règles à l'aide de tables et d'autres solutions?

DLH
la source
12

Je suppose qu'il 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? Mon patron s'en soucie-t-il? Mes utilisateurs s'en soucient-ils?

Google et d' autres systèmes automatisés font des soins, et ils sont tout aussi important dans de nombreuses situations. Le code sémantique est plus facile à analyser et à traiter pour un système non intelligent.

ceejayoz
la source
Oui, par exemple pour les blogs, le moteur sépare les commentaires du billet de blog. Imaginez que la mise en page a été conçue avec des tableaux ..
Omar Abid
2
-1: Google ne se soucie absolument pas si vous utilisez des tableaux pour la mise en page.
Tom Anderson
@Tom Anderson Non pas parce qu'ils ont un problème avec l'utilisation des tableaux pour la mise en page, mais simplement parce que le HTML non-tableau a tendance à être plus sémantique.
ceejayoz
8

Ayant dû travailler avec un site Web qui impliquait 6 couches de tables imbriquées générées par une application, et l'ayant fait générer du code HTML non valide, c'était en fait un travail de 3 heures pour rectifier la rupture pour un changement mineur.

C'est bien sûr le cas du bord, mais la conception basée sur une table n'est pas maintenable. Si vous utilisez css, vous séparez le style, donc lors de la correction du HTML, vous avez moins à vous soucier de la rupture.

Essayez également cela avec JavaScript. Déplacer une seule cellule de tableau d'un endroit à un autre endroit dans un autre tableau. Plutôt compliqué à réaliser où div / span fonctionnerait simplement du copier-coller.

"Est-ce que mon patron s'en soucie"

Si j'étais ton patron. Vous vous en souciez. ;) Si vous appréciez votre vie.

Kent Fredric
la source
Avoir dû travailler avec un site Web qui avait une énorme soupe de balises span et div et en avoir été témoin de la fragilité lors de la modification d'un seul élément casserait la page entière (et les divs utilisées au lieu des balises de titre) ...
inkredibl
L'utilisation de Div ne rend évidemment pas votre code plus agréable comme par magie. Il y a beaucoup à dire sur l'utilisation sémantique appropriée des balises.
Kent Fredric
7

Flexibilité de la mise en page
Imaginez que vous créez une page avec un grand nombre de miniatures.
DIVs :
Si vous placez chaque vignette dans un DIV, flottant à gauche, peut-être 10 d'entre elles tiennent sur une rangée. Rendez la fenêtre plus étroite et BAM - c'est 6 sur une rangée, ou 2, ou peu importe la taille.
TABLEAU:
Vous devez indiquer explicitement le nombre de cellules consécutives. Si la fenêtre est trop étroite, l'utilisateur doit faire défiler horizontalement.

Maintenabilité
Même situation que ci-dessus. Vous souhaitez maintenant ajouter trois miniatures à la troisième ligne.
DIVs:
ajoutez-les. La disposition s'ajustera automatiquement.
TABLEAU: collez les nouvelles cellules dans la troisième ligne. Oops! Maintenant, il y a trop d'articles là-bas. Coupez un peu de cette rangée et placez-les sur la quatrième rangée. Maintenant, il y a trop d'articles là-bas. Coupez un peu de cette ligne ... (etc)
( Bien sûr, si vous générez des lignes et des cellules avec des scripts côté serveur, ce ne sera probablement pas un problème. )

Nathan Long
la source
7

Je pense que ce bateau a navigué. Si vous regardez la direction que l'industrie a prise, vous remarquerez que CSS et Open Standards sont les gagnants de cette discussion. Ce qui signifie à son tour pour la plupart des travaux html, à l'exception des formulaires, les concepteurs utiliseront des div au lieu de tableaux. J'ai du mal avec ça parce que je ne suis pas un gourou CSS mais c'est comme ça.

Thomas Wagner
la source
5

N'oubliez pas non plus que les tableaux ne s'affichent pas très bien sur les navigateurs mobiles. Bien sûr, l'iPhone a un navigateur kick-ass, mais tout le monde n'a pas d'iPhone. Le rendu de tableau peut être des arachides pour les navigateurs modernes, mais c'est un tas de pastèques pour les navigateurs mobiles.

J'ai personnellement constaté que de nombreuses personnes utilisent trop de <div>balises, mais avec modération, elles peuvent être extrêmement propres et faciles à lire. Vous mentionnez que les gens ont plus de mal à lire les CSS que les tableaux; en termes de «code», c'est peut-être vrai; mais en termes de lecture de contenu (vue> source), il est beaucoup plus facile de comprendre la structure avec des feuilles de style qu'avec des tableaux.

Swati
la source
Bon point que vous avez là-bas; mais à mon humble avis, l'interface utilisateur pour les appareils mobiles devrait être complètement différente en tenant compte des limitations d'entrée.
Manrico Corazzi
Vrai; c'est pourquoi j'ai parfois commencé à utiliser une approche différente. Dans le modèle MVC, mon affichage ne fait apparaître que les données brutes XML, c'est-à-dire le contenu. Commencez ensuite avec un autre modèle MVC où les données brutes xml = modèle; view = html / css; contrôleur = xsl. La feuille de style XSL purge les données inutiles pour mobile.
Swati
5

On dirait que vous êtes juste habitué aux tables et c'est tout. Mettre la disposition dans un tableau vous limite uniquement pour cette disposition. Avec CSS, vous pouvez déplacer des bits, jetez un œil à http://csszengarden.com/ Et non, la mise en page ne nécessite généralement pas beaucoup de divs imbriqués.

Sans tableaux pour la mise en page et la sémantique appropriée, HTML est beaucoup plus propre, donc plus facile à lire. Pourquoi quelqu'un qui ne comprend pas CSS devrait-il essayer de le lire? Et si quelqu'un se considère comme un développeur Web, la bonne compréhension de CSS est un must.

Les avantages du référencement proviennent de la possibilité d'avoir le contenu le plus important en haut de la page et d'avoir un meilleur rapport contenu / balisage.

http://www.hotdesign.com/seybold/

Rimantas
la source
5
  • Conformité 508 - la possibilité pour un lecteur d'écran de comprendre votre balisage.
  • En attente de rendu - les tableaux ne s'affichent pas dans le navigateur jusqu'à ce qu'ils atteignent la fin de l' </table>élément.
Rick Glos
la source
Je me souviens d'avoir créé d'énormes tables il y a des années, à l'époque des ordinateurs plus lents, et je me souviens quand le code est arrivé qui les a rendues au fur et à mesure. IE6? IE4? Je ne m'en souviens pas, mais cela a certainement changé. Bien sûr, cela est utile pour les données tabulées, mais les tableaux de disposition sont stylisés à un pouce de leur vie, donc le rendu progressif serait peut-être moins utile car la table saute pour accueillir le contenu nouvellement chargé.
ijw
5

L'idée globale du balisage sémantique est la séparation du balisage et de la présentation, qui comprend la mise en page.

Les Div ne remplacent pas les tableaux, ils ont leur propre usage pour séparer le contenu en blocs de contenu connexe (,). Lorsque vous n'avez pas les compétences et que vous vous appuyez sur des tableaux, vous devrez souvent séparer votre contenu dans des cellules afin d'obtenir la mise en page souhaitée, mais vous n'aurez pas besoin de toucher le balisage pour effectuer la présentation lors de l'utilisation du balisage sémantique. Ceci est vraiment important lorsque le balisage est généré plutôt que des pages statiques.

Les développeurs doivent cesser de fournir un balisage qui implique une mise en page afin que ceux d'entre nous qui ont les compétences pour présenter du contenu puissent poursuivre nos travaux, et les développeurs n'ont pas à revenir à leur code pour apporter des modifications lorsque les besoins de présentation changent.

Steve Perks
la source
4

Il ne s'agit pas vraiment de savoir si les «divs sont meilleurs que les tableaux pour la mise en page». Quelqu'un qui comprend CSS peut dupliquer n'importe quelle conception en utilisant des «tableaux de disposition» assez facilement. La vraie victoire est d'utiliser des éléments HTML pour ce qu'ils sont là. La raison pour laquelle vous n'utiliseriez pas de tableaux pour des données non tabulaires est la même raison pour laquelle vous ne stockez pas des entiers sous forme de chaînes de caractères - la technologie fonctionne beaucoup plus facilement lorsque vous l'utilisez dans le but pour lequel elle est conçue. S'il a jamais été nécessaire d'utiliser des tableaux pour la mise en page (en raison des lacunes du navigateur au début des années 1990), ce n'est certainement pas le cas aujourd'hui.

domgblackwell
la source
3

Les outils qui utilisent des dispositions de tableau peuvent devenir extrêmement lourds en raison de la quantité de code requise pour créer la disposition. Le portail Netweaver de SAP utilise par défaut TABLE pour mettre en page leurs pages.

Le portail SAP de production de mon concert actuel a une page d'accueil dont le code HTML pèse plus de 60 Ko et va sept tables en profondeur, trois fois dans la page. Ajoutez le Javascript, l'utilisation abusive de 16 iframes avec des problèmes de table similaires à l'intérieur d'eux, CSS trop lourd, etc., et la page pèse plus de 5 Mo.

Prendre le temps de réduire le poids de la page afin que vous puissiez utiliser votre bande passante pour effectuer des activités engageantes avec les utilisateurs en vaut la chandelle.

Mike Cornell
la source
3

Cela vaut la peine de comprendre CSS et divs pour que la colonne de contenu centrale se charge et s'affiche avant la barre latérale dans une mise en page. Mais si vous avez du mal à utiliser des divs flottants pour aligner verticalement un logo avec du texte de parrainage, utilisez simplement le tableau et passez à la vie. La religion du jardin zen ne donne pas beaucoup pour son argent.

L'idée de séparer le contenu de la présentation est de partitionner l'application afin que différents types de travail affectent différents blocs de code. Il s'agit en fait de gestion du changement. Mais les normes de codage ne peuvent examiner l'état actuel du code que de manière superficielle.

Le journal des modifications d'une application qui dépend des normes de codage pour «séparer le contenu de la présentation» affichera un modèle de changements parallèles à travers les silos verticaux. Si un changement de "contenu" s'accompagne toujours d'un changement de "présentation", quel est le succès du partitionnement?

Si vous voulez vraiment partitionner votre code de manière productive, utilisez Subversion et consultez vos journaux de modifications. Ensuite, utilisez les techniques de codage les plus simples - divs, tables, JavaScript, inclut, fonctions, objets, continuations, peu importe - pour structurer l'application de sorte que les changements s'intègrent de manière simple et confortable.

Patrick May
la source
+1 pour les deux premières phrases.
Sean McMillan
3

Parce que c'est ENFER de maintenir un site qui utilise des tables et prend beaucoup de temps pour coder. Si vous avez peur des divs flottants, allez les suivre. Ils ne sont pas difficiles à comprendre et ils sont environ 100 fois plus efficaces et un million de fois moins douloureux (sauf si vous ne les comprenez pas - mais bon, bienvenue dans le monde des ordinateurs).

Quiconque envisage de faire sa mise en page avec une table ne devrait pas s'attendre à ce que je la maintienne. C'est le moyen le plus à l'envers pour rendre un site Web. Dieu merci, nous avons maintenant une bien meilleure alternative. Je ne reviendrai JAMAIS.

Il est effrayant que certaines personnes ne soient pas conscientes des avantages en termes de temps et d'énergie de la création d'un site à l'aide d'outils modernes.

Chuck Le Butt
la source
3

Les tableaux ne sont généralement pas plus faciles ni plus faciles à gérer que CSS. Cependant, il existe quelques problèmes de mise en page spécifiques où les tableaux sont en effet la solution la plus simple et la plus flexible.

CSS est clairement préférable dans les cas où le balisage de présentation et CSS prennent en charge le même type de conception, personne fontsensé ne dirait que les balises sont meilleures que la spécification de la typographie en CSS, car CSS vous donne le même pouvoir que font-tags, mais dans d'une manière beaucoup plus propre.

Le problème avec les tables, cependant, est essentiellement que le modèle de disposition de table en CSS n'est pas pris en charge dans Microsoft Internet Explorer. Les tableaux et CSS ne sont donc pas équivalents en puissance. La partie manquante est le comportement de type grille des tableaux, où les bords des cellules s'alignent verticalement et horizontalement, tandis que les cellules se développent toujours pour contenir leur contenu. Ce comportement n'est pas facile à obtenir en CSS pur sans coder en dur certaines dimensions, ce qui rend la conception rigide et fragile (tant que nous devons prendre en charge Internet Explorer - dans d'autres navigateurs, cela est facilement obtenu en utilisant display:table-cell).

Il ne s'agit donc pas vraiment de savoir si les tableaux ou CSS sont préférables, mais il s'agit de reconnaître les cas spécifiques où l'utilisation des tableaux peut rendre la mise en page plus flexible.

L' accessibilité est la raison la plus importante pour ne pas utiliser de tables. Les directives pour l'accessibilité du contenu Web http://www.w3.org/TR/WCAG10/ conseils à l'aide de tableaux de mise en page. Si vous êtes préoccupé par l'accessibilité (et dans certains cas, vous pouvez être légalement obligé de le faire), vous devez utiliser CSS même si les tableaux sont plus simples. Notez que vous pouvez toujours créer la même mise en page avec CSS qu'avec des tableaux, cela pourrait juste nécessiter plus de travail.

JacquesB
la source
3

J'ai été surpris de voir que certains problèmes n'étaient pas déjà couverts, voici donc mes 2 cents, en plus de tous les points très valables soulevés précédemment:

.1. CSS & SEO:

a) CSS a eu un impact très important sur le référencement en permettant de positionner le contenu dans la page où vous le souhaitez. Il y a quelques années, les moteurs de recherche accordaient une grande importance aux facteurs "en ligne". Quelque chose en haut de la page a été jugé plus pertinent pour la page que quelque chose situé en bas. "Haut de la page" pour une araignée signifiait "au début du code". En utilisant CSS, vous pouvez organiser votre contenu riche en mots clés au début du code, et toujours le positionner où vous le souhaitez dans la page. C'est encore quelque peu pertinent, mais les facteurs sur la page sont de moins en moins importants pour le classement des pages.

b) Lorsque la disposition est déplacée vers CSS, la page HTML est plus légère et se charge donc plus rapidement pour une araignée de moteur de recherche. (les araignées ne prennent pas la peine de télécharger des fichiers css externes). Le chargement rapide des pages est un facteur de classement important pour plusieurs moteurs de recherche, dont Google

c) Le travail SEO nécessite souvent de tester et de changer les choses, ce qui est beaucoup plus pratique avec une mise en page basée sur CSS

.2. Contenu généré:

Une table est considérablement plus facile à générer par programme que la présentation CSS équivalente.

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

La génération d'une table est simple et sûre. Il est autonome et s'intègre bien dans n'importe quel modèle. Faire la même chose avec CSS est considérablement plus difficile et peut ne présenter aucun avantage: difficile de modifier la feuille de style CSS en cours de route, et l'ajout du style en ligne n'est pas différent de l'utilisation d'un tableau (le contenu n'est pas séparé de la mise en page).

De plus, lorsqu'un tableau est généré, le contenu (en variables) est déjà séparé de la mise en page (en code), ce qui le rend aussi facile à modifier.

C'est une des raisons pour lesquelles certains sites Web très bien conçus (SO par exemple) utilisent toujours des dispositions de table.

Bien sûr, si les résultats doivent être traités via JavaScript, les div en valent la peine.

.3. Test de conversion rapide

Pour déterminer ce qui fonctionne pour un public spécifique, il est utile de pouvoir modifier la mise en page de différentes manières pour déterminer ce qui donne les meilleurs résultats. Une disposition basée sur CSS facilite considérablement les choses

.4. Différentes solutions pour différents problèmes

Les tableaux de disposition sont généralement disséqués car "tout le monde sait que les divs et CSS" sont la voie à suivre.

Cependant, le fait demeure que les tableaux sont plus rapides à créer, plus faciles à comprendre et plus robustes que la plupart des dispositions CSS. (Oui, CSS peut être aussi robuste, mais un coup d'œil rapide sur le net sur différents navigateurs et résolutions d'écran montre que ce n'est pas souvent le cas)

Il y a beaucoup d'inconvénients aux tables, y compris l'entretien, le manque de flexibilité ... mais ne jetons pas le bébé avec l'eau du bain. Il existe de nombreuses utilisations professionnelles pour une solution à la fois rapide et fiable.

Il y a quelque temps, j'ai dû réécrire une mise en page CSS propre et simple à l'aide de tableaux, car une partie importante des utilisateurs utiliseraient une ancienne version d'IE avec un très mauvais support pour CSS

Pour ma part, je suis malade et fatigué de la réaction instinctive "Oh non! Des tableaux pour la mise en page!"

Quant à la foule «ce n'était pas prévu à cet effet et donc vous ne devriez pas l'utiliser de cette façon», n'est-ce pas de l'hypocrisie? Que pensez-vous de toutes les astuces CSS que vous devez utiliser pour que le sacrément fonctionne dans la plupart des navigateurs? Étaient-ils destinés à cette fin?

Sylverdrag
la source