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

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.

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.

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.

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.

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.

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.

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.

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

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.

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!

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.

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.

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.

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 .

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.

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.

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?

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.

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.

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. )

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.

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.

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/

• 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.

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.

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.

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.

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.

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.

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.

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?