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

Il semble être le l'opinion générale que les tableaux ne doivent 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 contenu séparé de la mise en page

    mais c'est un argument fallacieux; Cliche Thinking . Je suppose qu'il est vrai que l'utilisation de l'élément table pour la mise en page a peu à voir avec les données tabulaires. Et alors? Est-ce que mon patron soins? Faire mes utilisateurs de soins?



    peut-être moi ou mes collègues développeurs qui doivent maintenir un soin de page web... Est un tableau moins maintenable? Je pense que l'utilisation d'une table est plus facile que l'utilisation de divs et CSS.



    au fait... pourquoi utiliser un div ou span bonne séparation du contenu de la mise en page et la table pas? 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 SEO de ne pas utiliser les tables

    pourquoi? Quelqu'un peut-il démontrer qu'il est? Ou d'une déclaration de Google que les tables sont découragés d'une perspective de SEO?

  • Les tableaux
  • et

    sont plus lents.

    un élément supplémentaire de carrosserie doit être inséré. Ce sont des cacahuètes pour les navigateurs Web modernes. Montrez-moi quelques repères où l'utilisation d'une table ralentit considérablement d'une page.

  • une révision de la disposition est plus facile sans tableaux, voir CSS Zen Garden .

    la plupart des sites Web qui ont besoin d'une mise à niveau ont aussi 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 beau site web, mais un peu théorique. Sans oublier son misuse de CSS.

je suis vraiment intéressé par les bons arguments pour l'utilisation de la vrd + CSS au lieu de tables.

665
demandé sur Benno Richters 2008-09-17 17:19:09
la source

30 ответов

je vais passer en revue vos arguments les uns après les autres 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, un Cliché de la 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 nouvelles expressions idiomatiques se sont développées dans d'autres langues), mais elle est possible. implications négatives être compensé. En outre, même s'il n'y avait pas d'arguments contre l'utilisation abusive de l'élément <table> aujourd'hui, il pourrait y avoir demain en raison de la façon dont les vendeurs de navigateur appliquent un traitement spécial à l'élément. Après tout, ils savent que " <table> éléments sont pour les données tabulaires seulement" et pourrait utiliser ce fait pour améliorer le moteur de rendu, dans le processus subtilement changer la façon dont <table> s se comportent, et donc briser les cas où il a été précédemment mal utilisé.

Et alors? Est-ce que mon patron soins? Faire mes utilisateurs de soins?

ça dépend. Est votre patron pointu à poil? Puis, il pourrait ne pas s'occuper. Si elle est compétente, alors elle s'en souciera, parce que les utilisateurs sera .

peut-être moi ou mes collègues développeurs qui doivent maintenir un soin de page web... Est un tableau moins maintenable? Je pense qu'utiliser une table est plus facile que d'utiliser divs et css.

la majorité des développeurs Web professionnels semblent s'opposer à vous [ citation neededed ] . Que les tableaux sont en fait moins maintenable devrait être évident. Utiliser des 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 cher. D'autre part, l'utilisation judicieuse de HTML sémantiquement significatif combiné avec CSS pourrait limiter ces changements à la CSS et les images utilisées.

soit dit en passant... pourquoi utiliser un div ou span bonne séparation du contenu et 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-modèle tout comme la disposition de la table. Les bons web designers n'ont pas besoin beaucoup d'entre eux. D'un autre côté, même des divs si profondément imbriqués n'ont pas beaucoup de problèmes de la disposition des tables. 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 comprennent css. C'est plus simple.

"la Plupart des gens n'ont pas d'importance. Les professionnels comptent. Pour les professionnels, tableau 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 le LaTeX parce que MS Word est plus simple pour la plupart des gens.

il est préférable pour SEO de ne pas utiliser les tables

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

Les Tables

sont plus lentes. Un élément supplémentaire de corps doit être inséré. Ce sont des cacahuètes pour les navigateurs Web modernes.

L'élément supplémentaire n'a rien à voir avec des tables est plus lent. D'autre part, l'algorithme de mise en page pour les tableaux est beaucoup plus difficile, le navigateur doit souvent attendre pour l'ensemble du tableau à la charge avant de commencer à disposition le contenu. De plus, la mise en cache du layout ne fonctionnera pas (CSS peut facilement être mis en cache). Tout cela a été mentionné auparavant.

me montrer 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. Je m'y intéresserais moi-même parce qu'il est juste que cet argument manque d'une certaine rigueur scientifique.

la plupart des sites Web qui ont besoin d'une mise à niveau ont aussi 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.

pas du tout. J'ai travaillé sur plusieurs cas où changer la conception a été simplifié par une séparation du contenu et de la conception. Il est souvent nécessaire de changer du code HTML, mais les changements seront toujours beaucoup plus confinés. En outre, des modifications de conception doivent parfois être apportées de manière dynamique. Considérons les moteurs de template comme celui utilisé par le système de blogs WordPress. La disposition des tables tuerait littéralement ce système. J'ai travaillé sur un cas similaire pour un logiciel commercial. Être capable de changer la conception sans changer le code HTML était l'une des exigences opérationnelles.

autre chose. La disposition de la Table rend l'analyse automatisée des sites web (screen scraping) beaucoup plus difficile. Cela peut sembler insignifiant parce que, après tout, qui le fait? J'ai été surpris moi-même. Screen scraping peut aider beaucoup si le service en question n'offre pas une alternative de service Web pour accéder à ses données. Je travaille en bioinformatique là où c'est une triste réalité. Les techniques modernes de web et WebServices N'ont pas atteint la plupart des développeurs et souvent, screen scraping est le seul moyen de automatiser le processus d'obtention des données. Pas étonnant que de nombreux biologistes toujours effectuer ces tâches manuellement. Pour les milliers de jeux de données.

497
répondu Konrad Rudolph 2010-08-01 22:42:14
la source

Voici mon réponse du programmeur d'un fil simliar

sémantique 101

regardez D'abord 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 "151960920 incorrecte". Il reflète mal sur le programmeur.

sémantique 102

appliquez maintenant ceci au balisage du document. Si votre document doit présenter des données tabulaires, alors l'étiquette appropriée serait <table> . Cependant, si vous placez la navigation dans une table, alors vous abusez de la fonction prévue de l'élément <table> . Dans le second cas, vous ne présentez pas de données tabulaires -- vous utilisez (mis) <table> élément permettant d'atteindre un objectif de présentation.

Conclusion

est-ce que les visiteurs remarqueront? Aucun. Est-ce que votre patron de soins? Peut-être. Est-ce qu'on prend parfois des raccourcis en tant que programmeurs? Assurer. Mais devrions-nous? Aucun. Qui bénéficie si vous utilisez le balisage sémantique? Toi ... et ta réputation professionnelle. Maintenant, allez et faire la bonne chose.

290
répondu Carl Camera 2017-05-23 14:54:58
la source

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 une table (rappelez-vous - le HTML ne change pas) alors par tous les moyens utiliser des tables pour la mise en page.

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

tous 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 mise en page basée sur une table la place dans le 3ème cellule de la 2e rangée de la 2ème table imbriquée sur la page.

donc vos réponses sont maintenabilité, accessibilité et SEO.

ne soyez pas paresseux. Faites les choses correctement et correctement même si elles sont un peu plus difficiles à apprendre.

104
répondu erlando 2008-09-17 17:33:01
la source

voir cette question en double.

un élément que vous oubliez, c'est l'accessibilité. Les mises en page basées sur des tableaux ne se traduisent pas aussi bien si vous avez besoin d'utiliser un lecteur d'écran, par exemple. Et si vous travaillez pour le gouvernement, la prise en charge des navigateurs accessibles comme les lecteurs d'écran peut être requis .

je pense aussi que vous sous-estimez l'impact de certaines choses que vous avez mentionnées dans la question. Par exemple, si vous êtes à la fois le concepteur et le programmeur, vous pourriez ne pas avoir une pleine appréciation de la façon dont il distingue la présentation du contenu. Mais une fois que vous obtenez dans un magasin où ils sont deux rôles distincts les avantages commencent à devenir plus claire.

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

91
répondu Joel Coehoorn 2017-05-23 15:10:33
la source

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

par conséquent, un site web dont le but est de montrer l'avantage de garder le design hors du contenu, commet maintenant régulièrement le péché innommable de mettre du contenu dans le design. (Si le titre de la section dans le fichier HTML devait changer, le titre de la section affiché ne serait pas).

ce qui montre que même ceux qui prônent la religion stricte DIV & CSS, ne peuvent pas suivre leurs propres règles. Vous pouvez vous en servir comme ligne directrice pour déterminer dans quelle mesure vous les suivez de près.

54
répondu James Curran 2008-09-17 18:09:16
la source

ce n'est pas l'argument définitif, par tous les moyens, mais avec CSS vous pouvez prendre le même markup et changer la disposition en fonction du médium, ce qui est un bel avantage. Pour une page d'impression, vous pouvez tranquillement supprimer la navigation sans avoir à créer une page facile à imprimer, par exemple.

48
répondu expedient 2008-09-17 17:23:22
la source

une table pour la disposition ne serait pas si mal. Mais vous ne pouvez pas obtenir la disposition dont vous avez besoin avec juste une table la plupart du temps. Bientôt, vous aurez 2 ou 3 tables imbriquées. Cela devient très encombrant.

  • C'est beaucoup plus difficile à lire. Ce n'est pas à la hauteur de l'opinion. Il y a juste plus d'étiquettes imbriquées sans aucune marque d'identification dessus.

  • séparer le contenu de la présentation est une bonne chose parce que ça te permet de te concentrer sur ce que tu fais. Mélanger les deux conduit à des pages gonflées qui sont difficiles à lire.

  • CSS for styles permet à votre navigateur de mettre en cache les fichiers et les requêtes subséquentes 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'ai pas besoin de changer le design a peu ici et là. Il est beaucoup plus facile avec les CSS.

  • Tables sont difficiles à coiffer. Vous n'avez pas beaucoup de flexibilité avec eux (i.e. vous avez encore besoin d'ajouter des attributs HTML pour contrôler pleinement les styles d'une table)

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

j'aimerais vraiment vous suggérer la lecture CSS Maestry par Andy Budd. C'est fantastique.

Image at 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
répondu Ben Scheirman 2010-05-02 01:48:56
la source

il est bon de séparer le contenu de la mise en page

Mais c'est un argument fallacieux; cliché de penser

c'est un argument fallacieux parce que les tables HTML sont layout! Le contenu est le données dans le tableau, la présentation est le tableau lui-même. C'est pourquoi il peut parfois être très difficile de séparer CSS de HTML. Vous ne séparez pas le contenu de la présentation, vous séparez présentation de présentation! Une pile de divs imbriqués n'est pas différente d'une table - c'est juste un ensemble différent d'étiquettes.

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 mise en page de la balise dans le HTML est étroitement couplée avec le 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 en fonction de leur contenu. J'ai passé des jours à essayer de faire fonctionner ce navigateur avec CSS et DIVs et ce fut un cauchemar complet. Nous sommes passés aux tables et tout simplement a fonctionné .

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 le souci pour nous. Je ne sais pas pourquoi les lecteurs d'écran ne peuvent pas traiter avec les tables bien, mais je suppose que si c'est la façon dont il est alors développeurs doivent gérer.

36
répondu 17 of 26 2011-11-15 00:18:06
la source

CSS/DIV - ce ne sont que des emplois pour les design boys, n'est-ce pas. Les centaines d'heures que j'ai passé à déboguer les problèmes DIV/CSS, à chercher sur Internet pour obtenir une partie de markup travailler avec un navigateur obscur - cela me rend fou. Vous faites un petit changement et toute la mise en page va horriblement mal - où à la mort est la logique dans cela. Passer des heures à déplacer quelque chose de 3 pixels de cette façon puis quelque chose d'autre de 2 pixels de l'autre pour les faire tous s'aligner. Cela semble tout simplement faux pour moi d'une certaine manière. Ce n'est pas parce que vous êtes puriste et que quelque chose "n'est pas la bonne chose à faire" que vous devez en faire usage au nième degré et en toutes circonstances, surtout si cela rend votre vie mille fois plus facile.

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

la seule raison pour laquelle tous ces arguments CSS / DIV se produisent est en raison du défaut de CSS en premier lieu et parce que les navigateurs ne sont pas compatibles entre eux et si elles si c'était le cas, la moitié des concepteurs de sites Web dans le monde seraient au chômage.

Lors de la conception d'un formulaire windows, vous n'essayez pas de déplacer les contrôles après vous avoir mis, donc je pense qu'il est étrange pour moi pourquoi vous voulez vous faire avec un formulaire web. Je ne peux tout simplement pas comprendre cette logique. Commencez par la mise en page et quel est le problème. Je pense que c'est parce que les designers aiment flirter avec la créativité, tandis que les développeurs d'applications sont plus concernés par en fait, faire fonctionner l'application, créer des objets d'affaires, mettre en œuvre des règles d'affaires, travailler sur la façon dont les bits de données des clients se rapportent les uns aux autres, s'assurer que la chose répond aux exigences des clients - vous 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 facile et plus logique dans la conception des formulaires. Nous avons souvent des choses plus importantes à nous soucier que la bonne sémantique de l'utilisation d'une table au-dessus d'un div.

affaire en question-d'après cette discussion, j'ai converti quelques SDT et SRT existants en divs. 45 minutes à essayer de tout aligner l'un à côté de l'autre 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 essayer de me faire comprendre - quelle justification possible avez-vous pour vouloir que je le fasse de toute autre manière!

23
répondu Peter Mortensen 2010-12-13 20:27:15
la source
La disposition

devrait être facile. Le fait qu'il y ait des articles écrits sur la façon d'obtenir une mise en page dynamique à trois colonnes avec en-tête et pied de page dans CSS montre que c'est un système de mise en page pauvre. Bien sûr, vous pouvez le faire fonctionner, mais il y a littéralement des centaines d'articles en ligne sur la façon de le faire. Il n'y a à peu près pas de tels articles pour une mise en page similaire avec des tables parce que c'est manifestement évident. Peu importe ce que vous dites contre les tables et en faveur de CSS, ce fait défait tout: a la disposition de base de trois colonnes dans CSS est souvent appelé"le Saint Graal".

si cela ne vous fait pas dire" WTF " alors vous devez vraiment poser le kool-aid maintenant.

j'adore CSS. Il offre des options de style étonnantes et quelques outils de positionnement cool, mais comme un moteur de mise en page il est déficient. Il faut un système de positionnement dynamique. Une façon simple d'aligner les boîtes sur plusieurs axes sans connaître leurs tailles en premier. Je ne donne pas une merde si vous l'appelez < table> ou ou n'importe quoi d'autre, 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 y a des caractéristiques manquantes, les zélotes CSS ont été de retenir CSS de tout ce qu'il pourrait être. Je serais parfaitement heureux d'arrêter d'utiliser des tables si CSS fourni un positionnement de grille multi-axes décent comme fondamentalement tous les autres moteurs de mise en page dans le monde. (Vous réalisez que ce problème a déjà été résolu de nombreuses fois dans de nombreux toutes les langues sauf le W3C, c'est ça? Et personne n'a nié qu'une telle fonctionnalité est utile.)

soupir. Assez de ventilation. Aller de l'avant et de coller votre tête en arrière dans le sable.

21
répondu needlestack 2011-11-02 03:56:03
la source

selon 508 compliance (pour les lecteurs d'écran pour les visually impared), les tableaux ne devraient être utilisés que pour contenir des données et non pour la mise en page, car cela fait paniquer les lecteurs d'écran. Ou alors j'ai dit.

si vous assignez des noms à chacune des divs, vous pouvez les dépouiller tous ensemble en utilisant CSS ainsi. C'est juste un peu plus pénible de s'asseoir comme on veut.

19
répondu Rob 2008-09-17 17:21:35
la source

Voici une section de 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 le même code qu'une mise en page 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 la table est le fait que je suis trop zélé avec mon indentation. Je suis sûr que la section Contenu aurait deux autres tables intégrées.

une Autre chose à penser: filesizes . J'ai trouvé que les mises en page basées sur des tableaux sont habituellement deux fois plus grandes que leurs homologues CSS. Sur notre bande passante à haut débit, ce n'est pas un gros problème, mais c'est sur les modems à accès commuté.

18
répondu Ross 2011-06-15 03:44:57
la source

j'aimerais ajouter que les mises en page basées sur div sont plus faciles à mantain, evolve, et refactor. Juste quelques changements dans le CSS pour réorganiser les éléments et c'est fait. D'après mon expérience, redessiner une mise en page qui utilise des tables est un cauchemar (plus s'il y a des tables imbriquées).

votre code a aussi un sens du point de vue sémantique .

14
répondu Guido 2008-09-17 17:28:37
la source

Pas d'arguments dans les DIVs faveur de moi.

je dirais : si la chaussure te va, porte-la.

Il est intéressant de noter qu'il est difficile, voire impossible, de trouver un bon DIV+CSS méthode de rendu de contenu en deux ou trois colonnes, qui est compatible sur tous les navigateurs, et a toujours l'air juste la façon dont j'ai prévu.

Cela fait pencher un peu la balance vers les tables dans la plupart de mes dispositions, 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 , le point de 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.

13
répondu Radu094 2008-09-17 17:48:40
la source

mises en forme CSS sont généralement beaucoup mieux pour l'accessibilité, à condition que le contenu est livré dans un ordre naturel et logique, sans une feuille de style. Et ce n'est pas seulement les lecteurs d'écran qui luttent avec les mises en page basées sur la table: ils rendent aussi beaucoup plus difficile pour les navigateurs mobiles de rendre une page correctement.

en outre, avec une mise en page basée sur div, vous pouvez très facilement faire des choses fraîches avec une feuille de style d'impression comme l'exclusion des en-têtes, des pieds de page et de la navigation à partir de pages imprimées - I pense qu'il serait impossible, ou du moins beaucoup plus difficile de le faire avec un tableau de mise en page.

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

de façon réaliste, je pense qu'il est très difficile de changez complètement la disposition d'un design basé 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.

13
répondu MB. 2008-09-17 18:19:31
la source

le fait qu'il s'agisse d'une question très débattue témoigne de l'incapacité du W3C à anticiper la diversité des schémas de configuration qui serait tentée. Utiliser divs+css pour une mise en page conviviale sur le plan sémantique est un excellent concept, mais les détails de la mise en œuvre sont tellement imparfaits qu'ils limitent en fait la liberté de création.

j'ai essayé de changer l'un des sites de notre société de tables à divs, et c'était un tel casse-tête que j'ai totalement abandonné les heures de travail J'avais versé dedans et je suis retourné aux tables. Essayer de lutter avec mes divs afin de prendre le contrôle de l'alignement vertical m'a maudit avec des problèmes psychologiques majeurs que je ne secouerai jamais aussi longtemps que ce débat fait rage.

le fait que les gens doivent souvent trouver des solutions de rechange complexes et laides pour atteindre des objectifs de conception simples (comme l'alignement vertical) suggère fortement que les règles ne sont pas assez flexibles. Si les spécifications sont suffisantes, alors pourquoi est-ce que les sites très en vue (comme ainsi) trouvent nécessaire de contourner les règles en utilisant des tables et d'autres solutions de rechange?

13
répondu DLH 2010-08-09 17:10:10
la source

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? Est-ce que mon patron soins? Faire mes utilisateurs de soins?

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

12
répondu ceejayoz 2008-09-17 17:23:33
la source

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 HTML invalide, c'était en fait un travail de 3 heures pour rectifier la rupture pour un changement mineur.

C'est bien sûr le cas de bord, mais la conception à base de table est impossible à maintenir. Si vous utilisez css, vous séparez le style de sorte que lors de la fixation du HTML vous avez moins à vous soucier de casser.

aussi, essayez ceci avec JavaScript. Déplacer une cellule de table d'un endroit à un autre dans une autre table. Plutôt compliqué à effectuer là où div / span ne ferait que travailler en mode copier-coller.

"est-ce que mon patron soins"

si j'étais votre patron. Vous voulez bien. ;) Si vous tenez à votre vie.

8
répondu Kent Fredric 2008-09-17 17:26:08
la source

Mise en page flexibilité

Imaginez que vous faites une page avec un grand nombre de vignettes.

DIVs :

Si vous mettez chaque vignette dans une DIV, flottés à gauche, peut-être que 10 d'entre eux vont sur une rangée. Faites la fenêtre plus étroite, et BAM - il est 6 sur une rangée, ou 2, ou combien de place.

TABLE:

" Vous devez explicitement dire combien de cellules sont dans une rangée. Si la fenêtre est trop étroite, l'utilisateur doit faire défiler horizontalement.

maintenabilité

Même situation que ci-dessus. Maintenant, vous voulez ajouter trois vignettes à la troisième rangée.

DIVs:

Les ajouter dans. La mise en page s'ajuster automatiquement.

TABLE: Coller les nouvelles cellules dans la troisième rangée. Oups! il y a trop d'éléments. Coupez - en un peu de cette rangée et mettez-les sur la quatrième rangée. Maintenant il y a trop d'éléments. Couper près de la ligne... (etc)

( bien sûr, si vous générez les lignes et les cellules avec des scripts côté serveur, ce ne sera probablement pas un problème. )

7
répondu Nathan Long 2008-09-17 19:09:34
la source

je pense que le bateau est parti. Si vous regardez la direction que l'industrie a prise, vous remarquerez que les normes CSS et les normes ouvertes sont les gagnants de cette discussion. Ce qui à son tour signifie pour la plupart des travaux html, à l'exception des formes, les concepteurs vont utiliser divs au lieu de tables. J'ai du mal avec ça parce que je ne suis pas un gourou CSS mais c'est comme ça.

7
répondu Thomas Wagner 2008-09-17 19:43:11
la source

en outre, n'oubliez pas, les tables ne rendent pas tout à fait bien sur les navigateurs mobiles. Bien sûr, l'iPhone a un navigateur génial, mais tout le monde n'a pas d'iPhone. Rendu de Table peut être cacahuète pour les navigateurs modernes, mais c'est un tas de pastèques pour les navigateurs mobiles.

j'ai personnellement constaté que beaucoup de gens utilisent trop de <div> balises, mais avec modération, il peut être extrêmement propre et facile à lire. Vous mentionnez que les gens ont plus de mal à lire CSS que tables; en termes de "code" qui 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 tables.

5
répondu Swati 2008-09-17 17:30:49
la source

on dirait que vous êtes juste habitué aux tables et c'est tout. Mettre la disposition dans une table vous limite pour juste cette disposition. Avec CSS vous pouvez déplacer des bits autour, jeter un oeil à 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 considère lui-même pour être webdeveloper puis la bonne compréhension de CSS est un must.

SEO les avantages viennent de la capacité d'avoir le contenu le plus important plus haut dans la page et avoir le meilleur contenu-à-balisage ratio.

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

5
répondu Rimantas 2008-09-17 17:31:18
la source
  • Conformité à l'article 508 - la possibilité pour un lecteur d'écran pour rendre le sens de votre balise.
  • en Attente de rendu des tables de ne pas afficher dans le navigateur jusqu'à ce qu'il arrive à la fin de la </table> élément.
5
répondu Rick Glos 2008-09-17 18:10:45
la source

toute l'idée autour du balisage sémantique est la séparation du balisage et de la présentation, qui inclut la mise en page.

Div's ne remplacent pas les tables, ils ont leur propre utilisation pour séparer le contenu en blocs de contenu lié (, ). Lorsque vous n'avez pas les compétences et sont en s'appuyant sur les tables, vous aurez souvent à séparer votre contenu dans les cellules afin d'obtenir la mise en page désirée, mais vous ne aurez pas besoin de toucher le markup pour atteindre la présentation lors de l'utilisation sémantique balisage. C'est vraiment important quand le markup est généré plutôt que des pages statiques.

les développeurs doivent arrêter de fournir un balisage qui implique la mise en page afin que ceux d'entre nous qui ont les compétences pour présenter le contenu peuvent continuer avec nos travaux, et les développeurs ne doivent pas revenir à leur code pour faire des changements lorsque la présentation a besoin de changement.

5
répondu Steve Perks 2008-09-17 18:52:38
la source

il ne s'agit pas vraiment de savoir si les "divs sont meilleurs que les tables pour la mise en page". Quelqu'un qui comprend CSS peut dupliquer n'importe quel design en utilisant des 'tables de mise en page' assez directement. La vraie victoire est d'utiliser des éléments HTML pour ce qu'ils sont là pour. La raison pour laquelle vous n'utiliseriez pas des tables pour des données non-tablulaires est la même raison pour laquelle vous ne stockez pas des entiers comme des chaînes de caractères - la technologie fonctionne beaucoup plus facilement quand vous l'utilisez pour le but pour lequel il est conçu. Si jamais il était nécessaire de utiliser des tableaux pour la mise en page (en raison de lacunes dans le navigateur au début des années 1990) ce n'est certainement pas maintenant.

4
répondu domgblackwell 2008-09-18 03:03:20
la source

les outils qui utilisent des layouts de table peuvent devenir extraordinairement lourds en raison de la quantité de code nécessaire pour créer le layout. Le portail Netweaver de SAP utilise par défaut TABLE pour mettre en page leurs pages.

le portail de production SAP à mon concert actuel a une page D'accueil dont le HTML pèse plus de 60K et va sept tables profondes, trois fois dans la page. Ajouter dans le Javascript, le mauvais usage 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 faire des activités engageantes avec les utilisateurs en vaut la peine.

3
répondu Mike Cornell 2008-09-17 19:22:24
la source

cela vaut la peine de calculer CSS et divs de sorte que la colonne centrale de contenu charge et rend 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 commandite, utilisez simplement la table et passez à autre chose. La religion du Jardin Zen ne donne pas grand-chose pour l'argent.

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

le journal des changements pour une application qui dépend de normes de codage pour" séparer le contenu de la présentation " montrera un modèle de changements parallèles à travers les silos verticaux. Si un changement de "contenu" est toujours accompagné par un changement de la "présentation", quelle est la répartition?

Si vous voulez vraiment partager votre code de manière productive, utilisez Subversion et examinez vos journaux de modifications. Ensuite, utilisez les techniques de codage les plus simples -- divs, tables, JavaScript, includes, functions, objects, continuations, whatever -- pour structurer l'application de sorte que les changements s'adaptent d'une manière simple et confortable.

3
répondu 2 revs, 2 users 71%Patrick May 2010-05-02 01:51:01
la source

parce que c'est L'enfer de maintenir un site qui utilise des tables, et prend beaucoup plus de temps à coder. Si vous avez peur de Floating divs, allez prendre un cours en eux. Ils ne sont pas difficiles à comprendre et ils sont environ 100 fois plus efficaces et un million de fois moins casse-couilles (à moins que vous ne les compreniez pas -- mais bon, Bienvenue dans le monde des ordinateurs).

si Quelqu'un envisage de faire sa mise en page avec une table, mieux vaut ne pas s'attendre à ce que je la maintienne. C'est l' la façon la plus rétrograde de rendre un site web. Dieu merci, nous avons une bien meilleure alternative maintenant. Je n'aurais JAMAIS revenir en arrière.

c'est effrayant que certaines personnes pourraient ne pas être au courant du temps et de l'énergie avantages de créer un site en utilisant des outils modernes.

3
répondu Chuck Le Butt 2010-11-29 21:45:50
la source

les Tableaux ne sont pas des en général plus facile ou plus facile à gérer que les CSS. Cependant, il y a quelques problèmes de disposition spécifiques où les tables 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 soutiennent le même type de conception, personne dans leur bon esprit ferait valoir que font - tags sont mieux que de spécifier la typographie dans CSS, puisque CSS vous donne la même puissance que font -tags, mais d'une manière beaucoup plus propre.

le problème avec les tables, cependant, est essentiellement que le modèle de table-layout dans CSS n'est pas pris en charge dans Microsoft Internet Explorer. Les tableaux et les CSS sont donc et non équivalents en puissance. La partie manquante est le grid-like behavior des tableaux, où les bords des cellules s'alignent à la fois verticalement et horizontalement, tandis que les cellules se développent encore pour contenir leur contenu. Ce comportement n'est pas facile à atteindre dans CSS pur sans hardcoding certaines dimensions, ce qui rend la conception rigide et fragile (aussi longtemps que nous devons soutenir Internet Explorer - dans d'autres navigateurs, c'est facile à atteindre en utilisant display:table-cell ).

donc ce n'est pas vraiment une question de savoir si les tables ou CSS sont préférables, mais c'est une question de reconnaître les cas spécifiques où l'utilisation des tables peut rendre la mise en page plus flexible.

le la raison la plus importante pour et non à l'aide de tableaux est l'accessibilité. The Web Content Accessibility Guidelines http://www.w3.org/TR/WCAG10 / conseil d'utilisation des tableaux pour la mise en page. Si vous êtes préoccupé par l'accessibilité (et dans certains cas vous pourriez être légalement obligé), vous devriez utiliser CSS même si les tables sont plus simples. Notez que vous pouvez toujours créer la même mise en page avec CSS qu'avec tables, il pourrait juste exiger plus de travail.

3
répondu JacquesB 2010-12-13 20:21:32
la source

j'ai été surpris de voir que certaines questions n'étaient pas déjà couvertes, alors voici mes 2 cents, en plus de tous les points très valables faits plus tôt:

.1. CSS& SEO:

a) le CSS utilisé pour avoir un impact très significatif sur le RÉFÉRENCEMENT en permettant de positionner le contenu de la page où vous voulez. Il y a quelques années, les moteurs de recherche accordaient une grande importance aux facteurs "sur la page". Quelque chose en haut de la page était jugé plus pertinent pour la page que quelque chose situé en bas. "Haut de page" pour une araignée signifie "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 voulez dans la page. Cela est encore un peu pertinent, mais les facteurs relatifs à la page sont de moins en moins importants pour le classement de la page.

b) lorsque la mise en page est déplacée vers CSS, la page HTML est plus légère et se charge donc plus rapidement pour un robot de moteur de recherche. (les araignées ne prennent pas la peine de télécharger des fichiers CSS externes). Pages de chargement rapide est une considération de classement important pour plusieurs moteurs de recherche, y compris Google

c) le travail de référencement nécessite souvent des tests et des changements, ce qui est beaucoup plus pratique avec une mise en page basée sur CSS

.2. contenu généré:

une table est beaucoup plus facile à générer programmiquement que le mise en page 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 beaucoup plus difficile et peut ne pas être bénéfique du tout: difficile d'éditer la feuille de style CSS sur le vol, et ajouter le style inline n'est pas différent de l'utilisation d'une table (le contenu n'est pas séparé de la mise en page).

en outre, quand une table est générée, le contenu (dans les variables) est déjà séparé de la mise en page (en code), le rendant aussi facile à modifier.

C'est l'une des raisons pour lesquelles certains sites web très bien conçus (donc par exemple) utilisent encore la disposition des tables.

bien sûr, si les résultats doivent être traités par JavaScript, les divs en valent la peine.

.3. conversion Rapide test

pour déterminer ce qui fonctionne pour un public spécifique, il est utile de capable de changer la mise en page de différentes façons pour comprendre ce qui obtient les meilleurs résultats. Une mise en page basée sur CSS facilite considérablement les choses

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

les tables de mise en page sont habituellement dissées parce que" tout le monde sait divs & CSS " sont la voie à suivre.

cependant le fait demeure que les tables sont plus rapides à créer, plus faciles à comprendre et sont plus robustes que la plupart des CSS disposition. (Oui, CSS peut être aussi robuste, mais un coup d'oeil rapide à travers 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 lançons pas le bébé avec l'eau du bain. Il ya beaucoup d'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 en utilisant des tables parce qu'une partie importante des utilisateurs utiliseraient une version plus ancienne de IE avec vraiment mauvais soutien pour CSS

moi, je suis malade et fatigué de la réaction réflexe "Oh non! Les 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 hypocrite? Que pensez-vous de tous les trucs CSS que vous devez utiliser pour obtenir la chose darn fonctionnement dans la plupart des navigateurs? Étaient-ils censés pour ce but?

3
répondu Sylverdrag 2011-04-11 15:59:25
la source

Autres questions sur