Pourquoi ne pas utiliser des tableaux pour la mise en page en HTML?
Il semble être opinion générale que les tableaux ne doivent pas être utilisés pour la présentation en HTML.
Pourquoi?
Je n'ai jamais (ou rarement pour être honnête) vu de bons arguments pour cela. Les réponses habituelles sont:
C'est bien de séparer le contenu de la mise en page
Mais c’est un argument fallacieux; Pensée Cliché . J'imagine qu'il est vrai que l'utilisation de l'élément de tableau pour la présentation a peu à voir avec les données tabulaires. Et alors? Est-ce que mon patron s'en fiche? Mes utilisateurs sont-ils concernés?
Peut-être moi ou mes collègues développeurs qui devons maintenir un entretien de page Web ... Une table est-elle moins maintenable? Je pense que l'utilisation d'une table est plus facile que d'utiliser divs et CSS.
Soit dit en passant ... pourquoi utiliser une div ou une étendue sépare-t-il bien le contenu de la mise en page et un tableau non? Obtenir une bonne mise en page avec seulement des div nécessite souvent beaucoup de div imbriquées.Lisibilité du code
Je pense que c'est l'inverse. La plupart des gens comprennent le HTML, peu de CSS.Il vaut mieux que le référencement n'utilise pas de tableaux
Pourquoi? Quelqu'un peut-il prouver qu'il en est ainsi? Ou une déclaration de Google selon laquelle les tables sont découragées du point de vue du référencement?Les tables sont plus lentes.
Un élément tbody supplémentaire doit être inséré. Ce sont des cacahuètes pour les navigateurs Web modernes. Montrez-moi des points de repère où l'utilisation d'un tableau ralentit considérablement une page.Une révision de la présentation est plus facile sans tableaux, voir css Zen Garden .
La plupart des sites Web nécessitant une mise à niveau ont également besoin d'un nouveau contenu (HTML). Les scénarios dans lesquels une nouvelle version d'un site Web nécessite uniquement un nouveau fichier CSS ne sont pas très probables. Zen Garden est un site web sympa, mais un peu théorique. Sans parler de son abus de CSS.
Je suis vraiment intéressé par de bons arguments pour utiliser divs + CSS au lieu de tableaux.
Je vais passer en revue vos arguments les uns après les autres et essayer de montrer leurs erreurs.
C'est bien de séparer le contenu de la mise en page Mais c'est un argument fallacieux; Cliché pensant.
Ce n'est pas fallacieux du tout parce que HTML a été conçu intentionnellement. Le mauvais usage 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 a pas d'argument contre l'utilisation abusive de l'élément <table> aujourd'hui, il pourrait y en avoir un 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 éléments <table> sont réservés aux données tabulaires" et pourraient utiliser ce fait pour améliorer le moteur de rendu, ce qui modifierait subtilement le comportement de <table>s et résoudrait ainsi les cas où il avait déjà été mal utilisé.
Et alors? Est-ce que mon patron s'en fiche? Mes utilisateurs sont-ils concernés?
Dépend. Votre patron a les cheveux pointus? Alors il pourrait ne pas s'en soucier. Si elle est compétente, alors elle s'en souciera, car les utilisateurs volonté .
Peut-être moi-même ou mes collègues développeurs qui devons maintenir un entretien de page Web ... Une table est-elle moins maintenable? Je pense que l'utilisation d'une table est plus facile que d'utiliser divs et css.
La majorité des développeurs Web professionnels semblent s'opposer à vous[ citation nécessaire ]. Que les tables soient en fait moins maintenables devraient être évidentes. L'utilisation de tableaux pour la mise en page signifie que modifier la mise en page de l'entreprise signifie en réalité changer chaque page. Cela peut être très coûteux. D'autre part, une utilisation judicieuse de HTML sémantiquement significatif associée à CSS pourrait limiter ces modifications au CSS et aux images utilisées.
Soit dit en passant, pourquoi utiliser une div ou une étendue sépare-t-il correctement le contenu de la présentation et un tableau? Obtenir une bonne mise en page avec seulement des div nécessite souvent beaucoup de div imbriquées.
Les <div>s profondément imbriqués sont un anti-motif au même titre que les dispositions de table. Les bons concepteurs Web n'ont pas besoin de beaucoup d'entre eux. D'un autre côté, même ces div imbriquées profondément ne posent pas beaucoup de problèmes de mise en page. 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" ne comptent pas. Les professionnels comptent. Pour les professionnels, les dispositions de table créent beaucoup plus de problèmes que HTML + CSS. Cela revient à dire que je ne devrais pas utiliser GVim ou Emacs parce que Notepad 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 vaut mieux que le référencement n'utilise pas de tableaux
Je ne sais pas si cela 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, ce sont rarement ce que les utilisateurs recherchent. Les utilisateurs recherchent des termes utilisés dans le titre de la page ou des positions similaires similaires. Il serait donc logique d'exclure le contenu tabulaire du filtrage et de réduire ainsi 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é. Ce sont des cacahuètes pour les navigateurs Web modernes.
L'élément supplémentaire n'a rien à voir avec le ralentissement des tables. En revanche, l’algorithme de mise en forme des tableaux est beaucoup plus complexe, le navigateur doit souvent attendre que tout le tableau se charge avant de pouvoir commencer à mettre en forme 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 des points de repère 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 nécessitant une mise à niveau ont également besoin d'un nouveau contenu (html). Les scénarios dans lesquels une nouvelle version d'un site Web nécessite uniquement un nouveau fichier CSS ne sont pas très 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 modifier du code HTML, mais les modifications seront toujours beaucoup plus limitées. En outre, les modifications de conception doivent parfois être effectuées de manière dynamique. Considérez les moteurs de modèles tels que celui utilisé par le système de blogging WordPress. Les dispositions de table tueraient littéralement ce système. J'ai travaillé sur un cas similaire pour un logiciel commercial. L'une des exigences de l'entreprise était de pouvoir modifier la conception sans changer le code HTML.
Autre chose. La disposition des tableaux rend l’analyse automatique des sites Web (suppression d’écran) beaucoup plus difficile. Cela peut sembler trivial car, après tout, qui le fait? J'ai été surpris moi-même. Le grattage d'écran peut être très utile si le service en question n'offre pas une alternative WebService pour accéder à ses données. Je travaille dans la bioinformatique où c'est une triste réalité. Les techniques Web modernes et les WebServices n’ont pas été consultés par la plupart des développeurs et, bien souvent, le grattage d’écran est le seul moyen d’automatiser le processus d’obtention des données. Il n'est donc pas étonnant que de nombreux biologistes effectuent encore de telles tâches manuellement. Pour des milliers d'ensembles de données.
Voici ma réponse du programmeur à partir d'un fil similaire
Sémantique 101
Jetez d'abord un coup d'œ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, est qu'un vélo n'est pas une voiture. La classe car est une classe inappropriée pour l'instance 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, la balise appropriée serait <table>. Cependant, si vous placez la navigation dans une table, vous vous servez du but de l'élément <table>. Dans le second cas, vous ne présentez pas de données tabulaires - vous utilisez (mal) l’élément <table> pour atteindre un objectif de présentation.
Conclusion
Les visiteurs remarqueront-ils? Non, votre patron s'en fiche? Peut être. Est-ce que nous coupons parfois les angles en tant que programmeurs? Sûr. Mais devrions-nous? Non. Qui profite si vous utilisez un balisage sémantique? Vous et votre réputation professionnelle. Maintenant, va faire la bonne chose.
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 des tableaux (rappelez-vous - le HTML ne change pas), utilisez des tableaux pour la mise en page.
L'accessibilité et le référencement sont deux autres aspects importants.
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 3ème cellule de la 2ème ligne du 2ème tableau imbriqué de la page.
Vos réponses sont donc la maintenabilité, l’accessibilité et le référencement.
Ne sois pas paresseux. Faites les choses comme il faut, même si elles sont un peu plus difficiles à apprendre.
Voir cette question en double.
Vous oubliez un élément: l’accessibilité. Les mises en page basées sur les tableaux ne 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 aussi que vous sous-estimez l'impact de certaines des choses que vous avez mentionnées dans la question. Par exemple, si vous êtes à la fois concepteur et programmeur, vous ne saurez peut-être pas tout à fait à quel point la présentation est séparée du contenu. Mais une fois que vous entrez dans un magasin où ils jouent deux rôles distincts, les avantages commencent à devenir plus clairs.
Si vous savez ce que vous faites et avez de bons outils, CSS présente réellement des avantages considérables par rapport aux tableaux pour la mise en page. Et bien que chaque élément en soi ne justifie pas l’abandon des tables, pris globalement, il en vaut généralement la peine.
Malheureusement, CSS Zen Garden ne peut plus être utilisé comme exemple de bonne conception HTML/CSS. Pratiquement toutes leurs conceptions récentes utilisent des graphiques pour les en-têtes 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 de contenu, engage désormais régulièrement le NAS impardonnable de la création de 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 défendent la religion stricte DIV & CSS ne peuvent pas suivre leurs propres règles. Vous pouvez utiliser cela comme une indication de la façon dont vous les suivez.
Ce n'est pas l'argument définitif, loin de là, mais avec CSS, vous pouvez utiliser le même balisage et modifier la mise en page en fonction du support, ce qui constitue un avantage appréciable. Pour une page imprimée, vous pouvez supprimer silencieusement 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 mise en page dont vous avez besoin avec une seule table la plupart du temps. Bientôt, vous avez 2 ou trois tables imbriquées. Cela devient très lourd.
C'est IS 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 cela vous permet de vous concentrer sur ce que vous faites. Le mélange des deux conduit à des pages surchargées difficiles à lire.
CSS pour les styles permet à votre navigateur de mettre en cache les fichiers et les demandes ultérieures sont beaucoup plus rapides. C'est énorme.
Les tableaux vous enferment dans un dessin. Bien sûr, tout le monde n’a pas besoin de la souplesse de CSS Zen Garden, mais je n’ai jamais travaillé sur un site où je n’ai pas eu besoin de modifier 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 complètement les styles d’un tableau).
Je n'ai pas utilisé de tableaux pour des données non tabulaires depuis probablement quatre ans. Je n'ai pas regardé en arrière.
Je voudrais vraiment suggérer la lecture Maîtrise CSS par Andy Budd. C'est fantastique.
Il est bon de séparer le contenu de la mise en page
Mais c’est un argument fallacieux; Pensée cliché
C'est un argument fallacieux parce que les tableaux HTML sont mis en page! Le contenu est le data dans la table, la présentation est la table elle-même. C'est pourquoi séparer CSS de HTML peut être très difficile parfois. 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 code HTML et du code 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 code HTML est étroitement associée au fichier CSS, quoi que vous fassiez.
Je pense que les tables vs divs se résument aux besoins de votre application.
Dans l’application que nous développons au travail, nous avions besoin d’une mise en page permettant aux pièces de se dimensionner dynamiquement par rapport à leur contenu. J'ai passé des jours à essayer de faire en sorte que cela fonctionne sur plusieurs navigateurs avec CSS et DIV, et c’était un cauchemar complet. Nous sommes passés à des tables et tout simplement travaillé.
Cependant, nous avons un public très fermé pour notre produit (nous vendons un élément matériel avec une interface Web) et les problèmes d’accessibilité ne nous concernent pas. Je ne sais pas pourquoi les lecteurs d'écran ne gèrent pas bien les tables, mais je suppose que si c'est comme ça, 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 consacrées au débogage des problèmes DIV/CSS, à la recherche sur Internet pour faire fonctionner une partie du balisage avec un navigateur obscur - c’est fou. Vous faites un petit changement et toute la structure va terriblement mal - où est la logique en cela. Passer des heures à déplacer quelque chose de 3 pixels de cette façon, puis quelque chose d’autre de 2 pixels l’autre pour les aligner. Cela me semble tout simplement faux. Ce n’est pas parce que vous êtes puriste et que quelque chose n’est "pas la bonne chose à faire" que vous devriez vous en servir au maximum et en toutes circonstances, surtout si cela vous facilite la vie mille fois.
J'ai donc finalement décidé, pour des raisons purement commerciales, même si je m'en sers au minimum, si je prévois 20 heures de travail pour placer une DIV correctement, je vais rester dans une table. C'est faux, ça choque les puristes, mais dans la plupart des cas, cela coûte moins de temps et coûte moins cher à gérer. Je peux alors me concentrer sur le fonctionnement de l'application à la demande du client, plutôt que de faire plaisir aux puristes. Après tout, ils paient les factures et mon argumentation à un responsable qui impose l'utilisation de CSS/DIV - je ferais simplement remarquer que les clients paient aussi son salaire!
La seule raison pour laquelle tous ces arguments CSS/DIV surviennent, c’est à cause de l’insuffisance de CSS en premier lieu et parce que les navigateurs ne sont pas compatibles les uns avec les autres et qu’ils le seraient, la moitié des concepteurs de sites Web dans le monde seraient au chômage. .
Lorsque vous concevez un formulaire Windows, vous n’essayez pas de déplacer les contrôles après les avoir disposés. Je pense donc que c’est étrange pour moi de vous expliquer pourquoi vous souhaitez procéder de la sorte avec un formulaire Web. Je ne peux tout simplement pas comprendre cette logique. Obtenez la bonne mise en page pour commencer et quel est le problème. Je pense que c’est parce que les concepteurs aiment flirter avec créativité, alors que les développeurs d’applications sont plus soucieux de faire fonctionner l’application, de créer des objets métier, d’appliquer des règles métier, de déterminer les liens entre les données client, de s’assurer qu’ils répondent aux attentes des clients. exigences - vous savez - comme le truc du monde réel.
Ne vous méprenez pas, les deux arguments sont valables, mais veuillez ne pas reprocher aux développeurs de choisir une approche plus simple et plus logique pour la conception de formulaires. Nous avons souvent des choses plus importantes à nous soucier que la sémantique correcte d’utiliser une table sur une div.
Exemple - sur la base de cette discussion, j’ai converti quelques tds et trs existants en divs. 45 minutes à jouer avec elle en essayant de tout aligner les unes à 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 possible avez-vous de vouloir que je le fasse autrement?
La mise en page devrait être facile. Le fait qu'il y ait 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 y a littéralement des centaines d'articles en ligne sur la façon de le faire. Il n’existe pratiquement pas d’articles de ce type pour une mise en page similaire avec des tableaux, car c’est évident. Peu importe ce que vous dites contre les tables et en faveur de CSS, ce seul fait annule tout: une mise en page de base à trois colonnes en CSS s'appelle souvent "Le Saint Graal".
Si cela ne vous fait pas dire "WTF", alors vous devez vraiment poser le kool-aid maintenant.
J'adore les CSS. Il offre des options de style incroyables et des outils de positionnement intéressants, mais en tant que moteur de présentation, il est déficient. Il doit exister un type de système de positionnement de grille dynamique. Un moyen simple d’aligner des boîtes sur plusieurs axes sans connaître leur taille au préalable. Je m'en fous si vous l'appelez <table> ou <gridlayout> ou autre chose, mais c'est une fonctionnalité de mise en page de base qui manque à CSS.
Le problème plus important est qu'en ne reconnaissant pas qu'il manque des fonctionnalités, les fanatiques de CSS ont retenu CSS de tout ce qu'il pourrait être. Je serais parfaitement heureux de cesser 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 du monde. (Vous réalisez que ce problème a déjà été résolu à de nombreuses reprises 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 de ventilation. Allez-y et mettez votre tête en arrière dans le sable.
Selon la conformité 508 (pour les lecteurs d’écran pour les impayés visuels), les tableaux ne devraient être utilisés que pour conserver des données et non pour la présentation car ils effraient les lecteurs. Ou alors on m'a dit.
Si vous attribuez des noms à chacun des divs, vous pouvez également les habiller tous ensemble à l'aide de CSS. Ils ont juste un peu plus de mal à s'asseoir comme vous en avez besoin.
Voici une partie du code 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 une table est le fait que je suis trop zélé avec mon indentation. Je suis sûr que la section de contenu contiendrait deux autres tableaux incorporés.
Une autre chose à considérer: taille du fichier. J'ai constaté que les mises en page basées sur des tables sont généralement deux fois plus grandes que leurs équivalents CSS. Sur notre haut débit haut débit, ce n’est pas un problème énorme mais c’est le cas de ceux qui disposent d’un modem.
J'aimerais ajouter que les mises en page basées sur les divisions sont plus faciles à gérer, à faire évoluer et à refactoriser. Juste quelques changements dans le CSS pour réorganiser les éléments et c'est fait. D'après mon expérience, redéfinir une mise en page utilisant des tableaux est un cauchemar (davantage s'il y a des tableaux imbriqués).
Votre code a également une signification d'un point de vue sémantique .
Les mises en page CSS sont généralement bien meilleures pour l'accessibilité, à condition que le contenu soit dans un ordre naturel et ait du sens sans feuille de style. Et ce ne sont pas seulement les lecteurs d'écran qui ont des difficultés avec les dispositions basées sur les tableaux: ils rendent également beaucoup plus difficile le rendu des pages par les navigateurs mobiles.
De plus, avec une mise en page basée sur div, vous pouvez très facilement faire des choses cool avec une feuille de style d'impression, telle que l'exclusion des en-têtes, des 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 basée sur la table.
Si vous croyez qu'il est plus facile de séparer le contenu de la présentation avec les divs qu'avec les tableaux, jetez un coup d'œil au code HTML basé sur des div présent sur CSS Zen Garden , et voyez comment la modification des feuilles de style peut modifier radicalement la présentation. et réfléchissez à la possibilité d’obtenir la même variété de dispositions si le code HTML était basé sur des tableaux ... Si vous utilisez une disposition basée sur des tableaux, il est peu probable que vous utilisiez CSS pour contrôler tout l’espacement et le remplissage du texte. cellules (si vous étiez, il serait presque certainement plus facile d’utiliser des divs flottantes, etc.). Sans utiliser CSS pour contrôler tout cela, et du fait que les tableaux spécifient les ordres de gauche à droite et de haut en bas dans le code HTML, les tableaux ont tendance à signifier que votre mise en page devient très fixe dans le code HTML.
En réalité, je pense qu'il est très difficile de changer complètement la présentation d'un design basé sur div et CSS sans changer un peu les div. Cependant, avec une mise en page basée sur div et CSS, il est beaucoup plus facile d’ajuster des choses telles que l’espacement entre différents blocs et leurs tailles relatives.
Le fait qu'il s'agisse d'une question très controversée témoigne de l'incapacité du W3C à anticiper la diversité des schémas de configuration qui seraient tentés. Utiliser divs + css pour une mise en page conviviale sur le plan sémantique est un bon concept, mais les détails de la mise en œuvre sont tellement imparfaits qu'ils limitent la liberté de création.
J'ai essayé de faire passer l'un des sites de notre société de tables en divs. J'avais tellement mal à la tête que j'ai complètement abandonné les heures de travail que je m'étais consacrées à ces tâches 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 tant que ce débat fera rage.
Le fait que les utilisateurs doivent souvent proposer 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 souples. Si les spécifications sont suffisantes, alors pourquoi les sites de premier plan (comme SO) jugent-ils nécessaire de contourner les règles à l'aide de tableaux et d'autres solutions de contournement?
Aucun argument en DIV ne favorise de moi.
Je dirais: si la chaussure vous va, portez-la.
Il est à noter qu'il est difficile, voire impossible, de trouver une bonne méthode DIV + CSS pour restituer le contenu sur deux ou trois colonnes, qui soit cohérente sur tous les navigateurs et qui ressemble toujours à ce que j'avais l'intention de faire.
Cela fait pencher la balance un peu vers les tables dans la plupart de mes mises en page, et même si je me sens coupable de les utiliser (dunny pourquoi, les gens disent simplement 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 tableaux. Je ne suis pas payé à l'heure, donc les tables sont moins chères pour moi.
J'imagine qu'il est vrai que l'utilisation de l'élément de tableau pour la présentation a peu à voir avec les données tabulaires. Et alors? Est-ce que mon patron s'en fiche? Mes utilisateurs sont-ils concernés?
Google et d’autres systèmes automatisés font 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.
Après avoir dû travailler avec un site Web comportant 6 couches de tables imbriquées générées par une application et l'avoir généré au format HTML non valide, il s'agissait en fait d'un travail de 3 heures pour le corriger en cas de modification mineure.
Ceci est bien sûr le cas Edge, mais la conception basée sur la table est intenable. Si vous utilisez css, vous séparez le style. Ainsi, lorsque vous corrigez le code HTML, vous avez moins à craindre de le casser.
Aussi, essayez ceci avec JavaScript. Déplacez une seule cellule d'un endroit à un autre dans une autre table. Plutôt compliqué à exécuter où div/span fonctionnerait comme un copier-coller.
"Est-ce que mon patron s'en fiche"
Si j'étais ton patron. Vous vous en soucieriez. ;) Si vous valorisez votre vie.
flexibilité de la mise en page
Imaginez que vous créez une page avec un grand nombre de vignettes.
DIVs:
Si vous placez chaque vignette dans une DIV, flottant à gauche, peut-être que 10 d'entre elles tiennent sur une ligne. Rendez la fenêtre plus étroite et BAM - c'est 6 sur une ligne, ou 2, ou peu importe la taille.
TABLE:
Vous devez indiquer explicitement le nombre de cellules 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 ligne.
DIVs:
Ajoutez-les. La disposition s’ajuste automatiquement.
TABLE: Collez les nouvelles cellules dans la troisième ligne. Oops! Maintenant, il y a trop d'articles là-bas. Couper certains de cette rangée et les mettre sur la quatrième rangée. Maintenant, il y a trop d'articles. Couper certains de cette ligne ... (etc)
(Bien sûr, si vous générez les lignes et les cellules avec un script côté serveur, cela ne posera probablement pas de problème.)
Je pense que ce bateau a navigué. Si vous regardez l'orientation prise par l'industrie, vous remarquerez que CSS et Open Standards sont les gagnants de cette discussion. Ce qui à son tour signifie pour la plupart des travaux HTML, à l'exception des formulaires, les concepteurs utiliseront des divs au lieu de tableaux. J'ai de la difficulté avec ça parce que je ne suis pas un gourou de CSS, mais c'est comme ça.
De plus, n'oubliez pas que les tableaux ne sont pas très bien rendus sur les navigateurs mobiles. Bien sûr, l'iPhone a un navigateur de premier plan, mais tout le monde n'a pas d'iPhone. Le rendu sur table peut être un avantage 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 balises <div>, mais que, avec modération, elles peuvent être extrêmement propres et faciles à lire. Vous dites que les gens ont plus de difficulté à lire les CSS que les tableaux; en termes de "code" que peut-être vrai; mais en termes de contenu (vue> source), il est beaucoup plus facile de comprendre la structure avec les feuilles de style qu'avec les tableaux.
On dirait que vous êtes juste habitué aux tables et c'est tout. Mettre une disposition dans un tableau vous limite pour cette disposition. Avec CSS, vous pouvez déplacer des éléments, consultez 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 une sémantique correcte, HTML est beaucoup plus propre, donc plus facile à lire. Pourquoi quelqu'un qui ne comprend pas le CSS devrait-il essayer de le lire? Et si quelqu'un se considère comme un développeur Web, alors la bonne compréhension de CSS est indispensable.
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.
L’idée générale autour du balisage sémantique est la séparation du balisage et de la présentation, ce qui inclut la mise en page.
Les div ne remplacent pas les tables, elles ont leur propre utilité en séparant le contenu en blocs de contenu apparenté (,). Lorsque vous ne possédez pas les compétences et que vous utilisez des tableaux, vous devrez souvent séparer votre contenu en cellules afin d'obtenir la mise en page souhaitée, mais vous n'aurez pas besoin de toucher au balisage pour obtenir une présentation lorsque vous utilisez un 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 proposer des balises impliquant une présentation afin que ceux d'entre nous qui possèdent les compétences nécessaires pour présenter du contenu puissent continuer à travailler, et que les développeurs n'aient pas à revenir à leur code pour apporter des modifications lorsque les besoins de présentation changent.
- Conformité 508 - possibilité pour un lecteur d’écran de donner un sens à votre marquage.
- En attente de rendu - les tables ne sont pas rendues dans le navigateur jusqu'à la fin de l'élément
</table>.
Il ne s'agit pas vraiment de savoir si "les div sont meilleurs que les tableaux pour la mise en page". Quelqu'un qui comprend le CSS peut dupliquer n'importe quelle conception en utilisant des "tableaux de présentation" 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 tables pour des données non-tablulaires est la même que vous ne stockez pas les entiers sous forme de chaînes de caractères - la technologie fonctionne beaucoup plus facilement lorsque vous l'utilisez à des fins spécifiques. S'il était nécessaire d'utiliser des tableaux pour la mise en page (en raison des lacunes du navigateur au début des années 90), ce n'est certainement pas le cas maintenant.
Il est utile de connaître les CSS et les divs pour que la colonne de contenu centrale se charge et s'affiche avant la barre latérale d'une mise en page. Mais si vous avez du mal à utiliser des divs flottantes pour aligner verticalement un logo avec un texte de parrainage, utilisez simplement le tableau et passez à autre chose. La religion du jardin zen ne donne pas grand-chose 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. C'est en fait une question 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 pour une application qui dépend des normes de codage pour "séparer le contenu de la présentation" indiquera un schéma de modifications parallèles sur des silos verticaux. Si un changement de "contenu" est toujours accompagné 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, suites, etc. - pour structurer l’application de sorte que les modifications s’adaptent de manière simple et confortable.
Les tableaux ne sont pas en général plus faciles ou plus faciles à gérer que CSS. Cependant, il existe quelques spécifiques problèmes de mise en page où les tableaux sont 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 de sensé ne peut prétendre que les balises font- sont meilleures que de spécifier une typographie en CSS, puisque CSS vous donne le même pouvoir que font- tags, mais d'une manière beaucoup plus propre.
Le problème avec les tableaux, cependant, est fondamentalement le fait que le modèle de disposition de table dans CSS n'est pas pris en charge dans Microsoft Internet Explorer. Les tables et CSS sont donc not équivalents en puissance. La partie manquante est le comportement en forme de grille des tableaux, où les bords des cellules s'alignent à la fois 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 les autres navigateurs, ceci est facilement réalisé en utilisant display:table-cell).
Il ne s'agit donc pas vraiment de savoir si les tableaux ou CSS sont préférables, mais bien de reconnaître les cas spécifiques dans lesquels l'utilisation de tableaux peut rendre la mise en page plus flexible.
L'accessibilité est la principale raison pour laquelle not utilise des tableaux. Les directives pour l'accessibilité au contenu Web http://www.w3.org/TR/WCAG10/ advice againt utilisant des tableaux pour la 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 que pour les tableaux, cela nécessitera peut-être plus de travail.
Les outils qui utilisent des présentations de table peuvent devenir extrêmement lourds en raison de la quantité de code requise pour créer la présentation. Le portail Netweaver de SAP utilise par défaut TABLE pour mettre en forme leurs pages.
Le portail SAP de production de mon poste actuel comporte une page d’accueil dont le code HTML pèse plus de 60 Ko et contient sept tables de profondeur, trois fois dans la page. Ajoutez 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 effectuer des activités engageantes avec les utilisateurs en vaut la peine.
La manipulation DOM est difficile dans une mise en page basée sur une table.
Avec div sémantique:
$('#myawesomediv').click(function(){
// Do awesome stuff
});
Avec des tables:
$('table tr td table tr td table tr td.......').click(function(){
// Cry self to sleep at night
});
Maintenant, d'accord, le deuxième exemple est un peu stupide, et vous pouvez toujours appliquer des identifiants ou des classes à une table ou à un élément td, mais ce serait ajouter de la valeur sémantique, ce à quoi les partisans de la table s'opposent tellement farouchement.
J'ai été surpris de voir que certains problèmes n'étaient pas déjà couverts. Voici donc mes 2 centimes, en plus de tous les points très valables qui ont été soulevés plus tôt:
.1. CSS & SEO:
a) Auparavant, CSS avait un impact considérable sur le référencement en permettant de positionner le contenu de la page où vous le souhaitez. Il y a quelques années, les moteurs de recherche accordaient une importance particulière aux facteurs "sur la page". Quelque chose en haut de la page était considéré comme plus pertinent 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 tout en le positionnant où vous le souhaitez dans la page. Ceci est encore un peu pertinent, mais sur la page, les facteurs sont de moins en moins importants pour le classement des pages.
b) Lorsque la mise en page est déplacée vers CSS, la page HTML est plus claire et se charge donc plus rapidement pour un moteur de recherche. (Les araignées ne se donnent 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, y compris Google.
c) Le travail de référencement nécessite souvent des tests et des modifications, ce qui est beaucoup plus pratique avec une mise en page basée sur CSS
.2. Contenu généré:
Il est beaucoup plus facile de générer par programme un tableau que la présentation CSS équivalente.
foreach ($comment as $key=>$value)
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}
Générer une table est simple et sûr. 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 ne présente aucun avantage: il est difficile de modifier la feuille de style CSS sur le vol, 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 présentation).
De plus, lorsqu’une table est générée, le contenu (en variables) est déjà séparé de la présentation (en code), ce qui le rend aussi facile à modifier.
C'est l'une des raisons pour lesquelles certains sites Web très bien conçus (SO par exemple) continuent à utiliser des tableaux.
Bien sûr, si les résultats doivent être exploités via JavaScript, les div en valent la peine.
.3. Test de conversion rapide
Lorsque vous déterminez ce qui fonctionne pour un public spécifique, il est utile de pouvoir modifier la disposition de différentes manières pour déterminer ce qui donne 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 tableaux de mise en page sont généralement dissed parce que "tout le monde sait divs & CSS" est la voie à suivre.
Cependant, il reste que les tables sont plus rapides à créer, plus faciles à comprendre et plus robustes que la plupart des mises en page CSS. (Oui, les CSS peuvent être aussi robustes, mais un rapide coup d'oeil 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 la maintenance, 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 forme CSS propre et simple à l'aide de tableaux, car une partie importante des utilisateurs utiliserait une ancienne version de IE avec un support vraiment médiocre pour CSS.
Pour ma part, j'en ai assez de la réaction instinctive "Oh non! Tableaux pour la mise en page!"
En ce qui concerne le "ce n'était pas prévu pour cela et donc vous ne devriez pas l'utiliser de cette façon", n'est-ce pas de l'hypocrisie? Que pensez-vous de tous les trucs CSS que vous devez utiliser pour faire fonctionner ce que vous faites dans la plupart des navigateurs? Étaient-ils destinés à cette fin?
Parce que c'est HELL de maintenir un site qui utilise des tables et prend beaucoup plus de temps pour coder. Si vous avez peur des divs flottantes, allez les suivre. Ils ne sont pas difficiles à comprendre et sont environ 100 fois plus efficaces et un million de fois moins pénibles (à moins que vous ne les compreniez 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 arriéré de rendre un site Web. Dieu merci, nous avons une bien meilleure alternative maintenant. Je n'y retournerai jamais.
Il est effrayant de constater que certaines personnes pourraient ne pas être conscientes des avantages en termes de temps et d'énergie générés par la création d'un site à l'aide d'outils modernes.
- Essayez de fusionner/scinder un colspan/rowspan profond de 10/20. Plus d'une fois, j'ai dû supprimer mon instinct pour me battre avec quelqu'un. [?!]
- Essayez de changer l'ordre du code source sans changer l'ordre visible. [SEO, utilisabilité, ...]
- La page (très simple) que nous consultons mesure environ 150 000 pages. Je parie qu'il peut presque être réduit de moitié en utilisant les CSS appropriés. [SEO (oui, référencement, lire les dernières spécifications Google, etc.), perfo, ...]
- Essayez de créer un modèle d'itérateur qui peut fonctionner dans n'importe quelle largeur.
- La discussion de la matière dans ce support de table de SO can provoque une singularité et nous détruit tous
Le problème de la séparation stricte de la présentation et du contenu me semble approximativement analogue à la séparation des fichiers d’en-tête des fichiers d’implémentation en C++. Cela a du sens, mais cela peut aussi être pénible. Témoin Java et C # où les classes sont définies dans un seul fichier source. Les auteurs des nouveaux langages ont remarqué quelque chose qui causait des maux de tête aux programmeurs et ils s'en sont débarrassés. Cela semble être l’essentiel de cette discussion. Un côté dit que le CSS est trop difficile, l'autre dit qu'il faut devenir un maître du CSS.
Pour les problèmes de mise en page simples, pourquoi ne pas modifier la règle selon laquelle la présentation doit être complètement séparée? Qu'en est-il d'une nouvelle balise (ou d'une extension de la balise div) qui nous permet de contrôler la présentation directement en HTML? Après tout, ne perdons-nous pas déjà la présentation en HTML? Regardez h1, h2 ... h6. Nous connaissons tous ces présentations de contrôle.
La capacité de lire du code (et HTML est un code) est très importante. Les gourous ont tendance à oublier l’importance de rendre un environnement de programmation aussi accessible que possible aux masses. Il est très myope de penser que seuls les programmeurs professionnels comptent.
Un gros problème pour moi est que le rendu des tables, en particulier des tables imbriquées, est beaucoup plus long qu'une implémentation CSS correctement présentée. (Vous pouvez rendre css aussi lent).
Tous les navigateurs rendent les fichiers css plus rapidement, car chaque div est un élément séparé, de sorte qu'un écran peut se charger pendant la lecture. (Pour d'énormes ensembles de données, etc.). Dans ce cas, j’ai utilisé css au lieu de tableaux, même pas de mise en page.
Une table imbriquée (tables à l'intérieur de cellules, etc.) ne sera pas rendue à la fenêtre du navigateur tant que le dernier "/ table" n'aura pas été trouvé. Pire encore: une table mal définie ne sera parfois même pas rendue! Ou alors, les choses se comportent mal. (ne colspanning pas correctement avec "TD", etc.)
J'utilise des tableaux pour la plupart des choses, mais lorsqu'il s'agit de gros volumes de données et de la volonté de disposer d'un rendu d'écran rapide pour un utilisateur final, je fais de mon mieux pour utiliser ce que CSS a à offrir.
J'ai eu à faire des sites de ces deux manières, plus un troisième, la redoutable "hybride" mise en page avec des tableaux, des div et des styles: Divs/CSS gagne, facilement.
Vous devez imbriquer trois divs profonds pour correspondre au poids du code d'une seule cellule du tableau, dès le départ. Cet effet est mis à l'échelle avec les tables imbriquées.
Je préférerais également effectuer un changement de présentation, par opposition à un changement pour chaque page de mon site.
J'ai le plein contrôle sur chaque aspect de la présentation avec divs/css. Les tableaux gâchent cela de manière hideuse, en particulier dans IE, un navigateur que je n'ai jamais eu l'option de ne pas supporter.
Mon temps pour la maintenance ou la refonte d'un site Web divs/css ne représente qu'une fraction de ce qu'il serait sous forme de tableaux.
Enfin, je peux innover de multiples dispositions commutables avec CSS et pratiquement tous les langages de script. Ce serait impossible pour moi avec des tables.
Bonne chance dans votre retour sur investissement lorsque vous prenez cette décision.
Un exemple: vous voulez centrer la zone de contenu principale d'une page, mais pour contenir les flottants à l'intérieur, elle doit être flottante. Il n'y a pas de "float: center" en CSS.
Ce n'est pas le seul moyen de "contenir les flotteurs" à l'intérieur d'un élément centré. Donc, pas un bon argument du tout!
D'une certaine manière, c'est une fausse prémisse, la chose "divs vs tables".
Division rapide et sale d'une page en trois colonnes? Les tableaux sont plus faciles, pour être honnête. Mais aucun professionnel ne les utilise plus pour la mise en page, car ils bloquent le positionnement des éléments de la page dans la page.
Le vrai argument est "positionnement effectué par CSS (heureusement dans un fichier distant)" par opposition à "positionnement effectué par HTML dans la page". Sûrement tout le monde peut voir les avantages de la première par opposition à la seconde?
- Taille - si votre mise en page est dans le code HTML, dans les pages, elle ne peut pas être mise en cache et doit être répétée sur chaque page. Vous économiserez d'énormes quantités de bande passante si votre mise en page se trouve dans un fichier CSS mis en cache, pas dans la page.
- Plusieurs développeurs peuvent travailler sur la même page en même temps - je travaille sur le HTML, d'autres personnes travaillent sur le CSS. Aucun référentiel nécessaire, pas de problème de surécriture, de verrouillage de fichier, etc.
- Effectuer des modifications est plus facile - il y aura des problèmes de mise en page dans différents navigateurs, mais il vous suffit de réparer un fichier, le fichier CSS, pour les trier.
- Accessibilité, comme mentionné beaucoup auparavant. Les tableaux supposent qu'une disposition bidimensionnelle fonctionne pour tout le monde. Ce n'est pas ainsi que certains utilisateurs voient votre contenu ni Google.
Considère ceci:
[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]
qui représente deux lignes d'un tableau avec 6 cellules. Quelqu'un qui peut voir la disposition de la table 2D verra une légende sous chaque image. Mais en utilisant la synthèse vocale, ou un PDA, et pour une araignée de moteur de recherche, c'est
picture picture picture caption caption caption
et la relation, évidente avec la table en place, disparaît.
Les DIV et CSS sont-ils meilleurs pour la tâche de simplement disposer des rectangles sur une page HTML pour réaliser un design donné dans les meilleurs délais? Non, ce n'est probablement pas le cas. Mais je ne suis pas en train de dessiner rapidement des rectangles pour obtenir un design donné. Je pense à une image beaucoup plus grande.
La séparation entre contenu et mise en forme facilite également la création de mises en page faciles à imprimer ou simplement de styles (styles) différents pour votre site, sans avoir à créer différents fichiers HTML. Certains navigateurs (comme Firefox) prennent même en charge la sélection d’une feuille de style dans le menu contextuel.
Et je pense qu'il est plus facile de maintenir une mise en page sans tableau. Vous n'avez pas à vous soucier des lignes, des colspans, etc. Vous créez simplement des divs de conteneur et placez le contenu là où vous en avez besoin. Et cela dit, je pense qu’il est également plus lisible (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
C'est juste un petit "truc" que vous devez apprendre (et une fois que vous maîtrisez le truc, je pense que c'est plus facile et plus logique).
Pour répondre à l'argument "les tables sont plus lentes" - vous envisagez de rendre le temps, ce qui est une métrique erronée. Très souvent, les développeurs vont écrire un énorme tableau pour faire la mise en page complète d'une page - ce qui ajoute de manière significative à la taille de la page à télécharger. Qu'on le veuille ou non, il y a encore une tonne d'utilisateurs d'accès à distance.
Voir aussi: utilisation excessive de ViewState
De l'expérience passée, je devrais aller pour DIV. Même en POO, l'objectif principal étant de réduire le couplage entre les objets, ce concept peut donc être appliqué aux DIVS et aux tables. Les tables sont utilisées pour conserver des données, pas pour les organiser autour d'une page. Une DIV est spécialement conçue pour organiser les éléments autour d'une page. La conception doit donc utiliser les DIV, les tables doivent être utilisées pour stocker les données.
De plus, éditer des sites web avec des tables est tout simplement difficile (à mon avis)
le positionnement de div et CSS permet une conception plus flexible, ce qui facilite la modification et la modélisation de vos pages Web.
Cela dit, si vous n'êtes pas intéressé par la flexibilité, alors utiliser une table plutôt que des div transformées en table par CSS est nettement plus facile et plus rapide à assembler. J'ai tendance à utiliser des tableaux lorsque j'écrase un dessin simplement pour que celui-ci ait l'air juste un peu plus vite.
Lorsque je conçois ma mise en page à l'aide de CSS, je donne généralement à chaque section majeure sa propre racine (niveau du corps), et j'utilise un positionnement relatif/absolu pour la placer à sa place. C'est un peu plus flexible que les tables, car je ne suis pas limité à un arrangement que je peux représenter en utilisant des lignes et des colonnes.
De plus, si je décide de réorganiser la présentation (disons que je veux que la barre de navigation se trouve tout de suite), je peux simplement modifier la position des éléments à un endroit (le fichier CSS) et du code HTML. pas besoin de changer. Si je le faisais avec des tables, je devrais entrer et trouver les informations et faire beaucoup de modding d'attribut et de copier/coller pour obtenir le même effet.
En fait, en utilisant CSS, je peux même laisser mes utilisateurs choisir comment ils veulent que leur mise en page fonctionne. Tant que la taille générale des zones de contenu ne change pas, l'utilisation d'un peu de script PHP pour produire mes CSS en fonction des préférences de l'utilisateur me convient parfaitement, tout en lui permettant de réorganiser le site. leur propre goût. Encore une fois, possible avec des tables, mais beaucoup plus difficile à maintenir.
Enfin, CSS offre un avantage MAJEUR que les tables ne fourniront jamais: la possibilité de reformater le contenu en fonction du périphérique d’affichage. CSS me permet d'utiliser un jeu de styles complètement différent (notamment la position, le formatage, etc.) d'une imprimante par rapport à celui que j'utilise pour le moniteur. Ceci peut également être étendu à d'autres médias. Un excellent exemple est Opera Show, qui permet de visualiser sous forme de diaporama une page CSS améliorée, conçue de manière très standard.
En fin de compte, flexibilité et gestion sont les véritables gagnants. Généralement, CSS vous permet de faire plus avec la mise en page. Il n'y a rien techniquement non standard à propos d'une disposition basée sur une table, mais pourquoi voudriez-vous vous limiter?
Auparavant, les lecteurs d'écran et autres logiciels d'accessibilité rencontraient des difficultés pour manipuler les tables de manière efficace. Dans une certaine mesure, cela a été traité dans les lecteurs d’écran par le fait que le lecteur bascule entre un mode "tableau" et un mode "présentation" en fonction de ce qu’il voyait à l’intérieur du tableau. Cela était souvent faux et les utilisateurs devaient donc basculer manuellement le mode lors de la navigation dans les tableaux. Dans tous les cas, les tables volumineuses, souvent très imbriquées, étaient, et dans une large mesure, toujours très difficiles à naviguer à l'aide d'un lecteur d'écran.
Il en va de même lorsque des div ou d'autres éléments de niveau bloc sont utilisés pour recréer des tables et sont fortement imbriqués. Les divs doivent être utilisés en tant qu'éléments de présentation et de présentation, et sont donc destinés à contenir des informations similaires et à les afficher à l'écran pour les utilisateurs visuels. Lorsqu'un lecteur d'écran rencontre une page, il ignore souvent les informations de mise en page, qu'elles soient basées sur CSS ou sur les attributs html (ceci n'est pas vrai pour tous les lecteurs d'écran, mais pour les plus populaires tels que JAWS, Windows Eyes et Orca pour Linux c'est).
À cette fin, les données tabulaires, c’est-à-dire les données qui ont un sens logique, doivent être placées dans des tableaux et utiliser des divs pour gérer la mise en forme du contenu de la page. (Une autre façon de penser à ce qu'est une "donnée tabulaire" est d'essayer de la dessiner sous forme de graphique ... si vous ne le pouvez pas, elle n'est probablement pas mieux représentée dans un tableau)
Enfin, avec une disposition basée sur des tableaux, afin de permettre un contrôle fin de la position des éléments sur la page, des tableaux hautement imbriqués sont souvent utilisés. Cela a deux effets: 1.) Augmentation de la taille du code pour chaque page - Etant donné que la navigation et la structure commune sont souvent effectuées avec les tables, le même code est envoyé sur le réseau pour chaque demande, alors qu'une mise en page basée sur div/css extrait le fichier css sur une fois, puis utilise des divs moins verbeuses. 2.) Le rendu du navigateur du client prend beaucoup plus de temps pour les tables hautement imbriquées, ce qui entraîne des temps de chargement légèrement plus lents.
Dans les deux cas, l'augmentation de la bande passante du "dernier kilomètre" et des ordinateurs personnels beaucoup plus rapides atténuent ces facteurs, mais ils restent néanmoins des problèmes existants pour de nombreux sites.
Comme tout le monde l’a dit, les tableaux sont plus faciles, car ils sont davantage orientés sur la grille, ce qui permet de moins réfléchir. Si le site en question n’est pas censé durer longtemps, ou ne sera pas maintenu, il pourrait être judicieux de faire ce qui est le plus facile, car c’est peut-être le plus rentable. Toutefois, si la base d'utilisateurs envisagée peut inclure une partie importante d'individus handicapés ou si le site sera maintenu par d'autres pendant longtemps, passer le temps à l'avance de faire les choses de manière concise et accessible peut s'avérer plus rentable.
Je ne comprends toujours pas tout à fait comment divs/CSS facilite la modification de la conception d'une page lorsque vous prenez en compte le nombre de tests requis pour vous assurer que les modifications fonctionnent sur tous les navigateurs, en particulier avec tous les hacks, etc. C'est un processus extrêmement frustrant et fastidieux qui gaspille beaucoup de temps et d'argent. Heureusement, la législation 508 ne s’applique qu’aux États-Unis (pays du libre - ouais, c'est vrai) et, du fait que je suis basé au Royaume-Uni, je peux développer des sites Web dans le style de mon choix. Contrairement à la croyance populaire (américaine), la législation de Washington ne s’applique pas au reste du monde - Dieu merci. Le jour de l’entrée en vigueur de la législation, le monde de la conception Web a dû passer une bonne journée. Je pense que je deviens de plus en plus cynique à mesure que je vieillis avec 25 ans dans l'industrie des technologies de l'information, mais je suis convaincu que ce type de législation vise uniquement à protéger les emplois. En réalité, tout le monde peut créer une page Web raisonnable avec quelques tableaux. Cela nécessite beaucoup plus d’efforts et de connaissances pour le faire avec DIVs/CSS. D'après mon expérience, cela peut prendre des heures et des heures à googler pour trouver des solutions à des problèmes assez simples et à la lecture d'articles incompréhensibles sur des forums remplis de fanatiques idéalistes, tous discutant de la "bonne" façon de faire les choses. Vous ne pouvez pas plonger vos pieds dans l'eau et faire en sorte que les choses fonctionnent correctement dans tous les cas. Il me semble également que l’absence d’un guide définitif sur l’utilisation de DIVS/CSS "clé en main", qui s’applique à toutes les situations, fonctionne sur des navigateurs, et écrit dans une langue "normale" sans langage geek, dégage également une odeur douteuse. peu de protectionnisme.
Je suis un développeur d’applications et je dirais qu’il faut presque deux fois plus de temps pour résoudre les problèmes d’agencement et les tester avec tous les navigateurs que pour créer l’application de base, concevoir et implémenter des objets métier et créer la base de données. back end. Mon temps = argent, à la fois pour moi et mes clients, donc je suis désolé si je ne rejette pas tous les arguments pro DIV/CSS en faveur de la réduction des coûts et de l'optimisation des ressources pour mes clients. C’est peut-être simplement la façon dont les développeurs pensent, mais il me semble bien plus facile de modifier une structure de tableau complexe que de modifier DIV/CSS. Heureusement, il apparaît maintenant qu'une solution à ces problèmes est maintenant disponible - elle s'appelle WPF.
Je pense que personne ne se soucie de la façon dont un site Web a été conçu/mis en œuvre lorsqu'il se comporte bien et qu'il fonctionne rapidement.
J'utilise les balises "table" et "div"/"span" dans le balisage HTML.
Laissez-moi vous donner quelques arguments pour expliquer pourquoi je choisis des divs:
pour une table, vous devez écrire au moins 3 balises (table, tr, td, thead, tbody), pour un joli design, parfois vous avez beaucoup de tables imbriquées
J'aime avoir des composants sur la page. Je ne sais pas comment expliquer exactement mais j'essaierai. Supposons que vous ayez besoin d'un logo et que celui-ci doive être placé, juste un petit morceau, sur le contenu de la page suivante. À l’aide de tableaux, vous devez découper 2 images et les placer dans 2 TD différents. En utilisant DIV, vous pouvez utiliser un simple CSS pour l’organiser à votre guise. Quelle solution préférez-vous?
quand plus de 3 tables imbriquées pour faire quelque chose, je pense à le redessiner en utilisant DIV
MAIS j'utilise encore des tables pour:
données tabulaires
contenu qui se développe soi-même
solutions rapides (prototypes), car le modèle de boîte DIV est différent sur chaque navigateur, car de nombreux générateurs utilisent des tables, etc.
En utilisant encore la table pour les mises en page, nous manquons d’innovation du côté div.
Beaucoup ont proposé des solutions qui facilitent la création d'une mise en page pour les divs. Le plus populaire étant l'architecture en grille. Il existe des générateurs de disposition dynamiques basés sur cette architecture. Découvrez: 1) 960.gs et (http://grids.heroku.com/) 2) blueprint et beaucoup de ces derniers temps.
Je n'ai pas vu beaucoup d'innovation en termes d'architecture et d'outils avec la disposition des tables.
Je dirais que toutes les théories mises à part, pratiquement la mise en page avec CSS et les divs sont plus rapides. L'innovation dans cette direction a plutôt rendu la tâche plus facile que tout.
Les tableaux sont bons pour le HTML que vous liez ensemble pour quelque chose de simple ou temporaire. Si vous construisez un site Web à grande échelle, vous devriez utiliser div et CSS, car il sera plus facile à maintenir à mesure que votre site Web change.
1: Oui, vos utilisateurs se soucient. S'ils utilisent un lecteur d'écran, il sera perdu. Si j'utilise un autre outil qui tente d'extraire des informations de la page, la rencontre de tableaux qui ne sont pas utilisés pour représenter des données tabulaires est trompeuse.
Une div ou un span est acceptable pour séparer le contenu car c'est précisément le sens de ces éléments. Lorsque, en tant que moteur de recherche, lecteur d'écran ou quoi que ce soit d'autre, je rencontre un élément de table, cela signifie que "les données suivantes sont des données tabulaires, représentées dans une table". Lorsque nous rencontrons un div, nous nous attendons à ce que "ceci soit un élément utilisé pour div mon contenu dans des parties ou des zones séparées.
2: Lisibilité: incorrecte. Si tout le code de présentation est en css, je peux lire le code HTML et je vais comprendre le contenu de la page. Ou je peux lire le css et comprendre la présentation. Si tout est mélangé dans le code HTML, je dois effacer mentalement tous les éléments liés à la présentation avant même de voir ce qui est contenu et ce qui ne l'est pas. De plus, j'aurais peur de rencontrer un développeur Web qui ne comprend pas le CSS, alors je ne pense vraiment pas que ce soit un problème.
3: Les tables sont plus lentes: oui, elles le sont. La raison est simple: les tableaux doivent être complètement analysés, y compris leur contenu avant de pouvoir être rendus. Un div peut être rendu quand il est rencontré, même avant son contenu a été analysé. Cela signifie que les divs apparaîtront avant que le chargement de la page ne soit terminé.
De plus, les tableaux sont beaucoup plus fragiles et ne seront pas toujours restitués de la même manière dans différents navigateurs, avec des polices et des tailles de police différentes, ainsi que tous les autres facteurs pouvant entraîner une modification de la présentation. Les tableaux sont un excellent moyen de s’assurer que votre site sera désactivé d’un pixel ou deux dans certains navigateurs, ne sera pas mis à l’échelle si l’utilisateur modifie la taille de sa police ou modifie ses paramètres de toute autre manière.
Bien sûr, le n ° 1 est le plus important. Beaucoup d'outils et d'applications dépendent de la signification sémantique d'une page Web. L'exemple habituel est celui des lecteurs d'écran pour les utilisateurs malvoyants. Si vous êtes un développeur Web, vous constaterez que de nombreuses grandes entreprises qui pourraient autrement vous engager pour travailler sur un site, exigent que le site soit accessible même dans ce cas. Ce qui signifie que vous devez réfléchir à la signification sémantique de votre code HTML. Avec le Web sémantique, ou plus précisément, les microformats, les lecteurs rss et d’autres outils, le contenu de votre page n’est plus visualisé exclusivement par le biais d’un navigateur.
Je suis désolé pour mon anglais mais voici une autre raison:
J'ai travaillé dans une organisation gouvernementale et la principale raison de ne pas utiliser TABLE est pour les personnes handicapées. Ils utilisent des machines pour "traduire" des pages Web.
Le problème est que cette "machine de traduction" ne peut pas lire le site Web si c'est fait par TABLE. Pourquoi ? Parce que TABLE sont pour DATAS.
en fait, si vous utilisez des TABLES, vous devez spécifier, pour chaque CELLULE, des informations permettant aux personnes handicapées de savoir où elles se trouvent dans le TABLEAU. Imaginez que vous ayez un grand tableau et que vous deviez zoomer pour ne voir qu'une cellule à l'écran: vous devez savoir dans quelle ligne/col vous vous trouvez.
Ainsi, les DIV sont utilisés et les personnes handicapées peuvent simplement lire du texte et ne pas obtenir d’informations étranges sur les lignes/colonnes quand elles n’ont pas besoin d’être là.
Je préfère aussi TABLE pour créer des modèles rapides et faciles, mais je suis maintenant habitué au CSS ... c'est puissant, mais vous devez vraiment savoir ce que vous faites ... :)
Flex a une balise pour disposer les éléments en colonnes verticales. Pour être honnête, je ne pense pas qu'ils aient compris tout le contenu de la mise en page/du contenu, mais au moins ils ont résolu le problème.
Comme beaucoup de personnes frustrées par le CSS, je cherchais facilement une réponse facile. Je me sentais ravie de l'avoir trouvée, puis mes espoirs se sont brisés lorsque j'ai ouvert la page dans Chrome. Je ne suis certainement pas assez expérimenté pour dire que ce n'est pas possible, mais je n'ai vu personne offrir un exemple de code pour examen par les pairs prouvant sans équivoque que cela peut être fait de manière fiable.
Alors, quelqu'un du côté CSS de cette île peut-il recommander un état d'esprit/une méthodologie pour la disposition des colonnes verticales? J'ai essayé le positionnement absolu dans les deuxième et troisième rangées, mais je finis par avoir des éléments qui se chevauchent partout. Flot a des problèmes similaires si la page est réduite.
S'il y avait une réponse à cela, je serais ravi de - ( faire la bonne chose - Dites-moi quelque chose comme, "Hey, as-tu essayé ** flow: vertical | horizontal" et je suis totalement hors de tes cheveux.
Google accorde une très faible priorité au contenu textuel contenu dans un tableau. Je donnais des conseils de référencement à un organisme de bienfaisance local. En examinant leur site Web, il utilisait des tableaux pour mettre en page le site. En regardant chaque page, quels que soient les mots - ou la combinaison de mots - de leurs pages que j'ai utilisées dans le champ de recherche Google, les pages n'apparaissent dans aucune des pages de recherche supérieures. (Cependant, en spécifiant le site dans la recherche, la page a été renvoyée.) Une page a bien été copiée selon les normes habituelles pour produire un bon résultat dans une recherche, mais elle n’apparaissait pas dans les premières pages des résultats de recherche. . (Notez que ce texte se trouvait dans un tableau.) J'ai ensuite repéré une section de texte sur les pages qui était dans un div plutôt qu'un tableau. Nous avons mis quelques mots de cette div dans le moteur de recherche. Résultat? Il est entré au n ° 2 dans le résultat de la recherche.
Une fois, j’ai appris qu’une table se chargeait en une fois, c’est-à-dire qu’une connexion est lente, l’espace où la table est livrée reste vide jusqu’à ce que la table entière soit chargée. Par contre, un div se charge de haut en bas dès que les données arrivent. et peu importe si elle est déjà complète ou non.
Utilisez des tableaux lorsque vous devez vous assurer que les éléments doivent rester dans une relation physique spécifique dans la présentation. Pour les données, la table est généralement le meilleur élément de présentation à utiliser, car vous ne souhaitez pas que vos colonnes soient enveloppées de manière inattendue et confondent les associations.
On pourrait également argumenter que les éléments non-données qui doivent rester dans une relation spécifique devraient également être restitués dans un tableau.
Les mises en forme flex flexibles conviennent parfaitement au contenu adapté aux appareils mobiles, aux grands écrans, à l'impression et à d'autres types d'affichage, mais parfois, le contenu doit simplement être affiché de manière très spécifique et si cela nécessite que les lecteurs d'écran ne puissent pas y accéder facilement, cela pourrait très bien être justifié.
J'essaie d'éviter autant que possible les TABLE, mais lorsque nous concevons des formulaires complexes qui combinent plusieurs types de contrôles et différentes positions de légende avec des contrôles assez stricts sur le groupement, l'utilisation de DIV n'est pas fiable ou est presque impossible.
Maintenant, je ne discuterai pas du fait que ces formulaires ne pourraient pas être repensés pour mieux s'adapter à une présentation basée sur DIV, mais pour certains d'entre eux, notre client est résolu à ne pas modifier les présentations existantes de la version précédente (écrites en ASP classique) car formulaire papier que leurs utilisateurs connaissent.
Étant donné que la présentation des formulaires est dynamique (l'affichage de certaines sections étant basé sur l'état du cas ou sur les autorisations de l'utilisateur), nous utilisons des ensembles de DIV empilés, chacun contenant un TABLEAU d'éléments de formulaire regroupés logiquement. Chaque colonne de la table est classée afin qu’elles puissent être contrôlées par CSS. De cette façon, nous pouvons désactiver différentes sections du formulaire sans le problème de ne pas être un tableau pour envelopper des lignes dans des DIV.
J'ai étudié la question des lecteurs d'écran et des tableaux il y a quelques années et j'ai trouvé des informations qui contredisent ce que la plupart des développeurs croient:
http://www.webaim.org/techniques/tables/
"Vous allez probablement entendre des défenseurs de l'accessibilité dire que les tableaux de mise en forme sont une mauvaise idée et que les techniques de mise en forme CSS doivent être utilisées. Il y a du vrai dans ce qu'elles disent, mais, pour être honnête, utiliser des tableaux pour la mise en page n'est pas le pire Ce que vous pouvez faire en termes d’accessibilité. Les personnes souffrant de tous types de handicaps peuvent facilement accéder aux tables, à condition que les tables soient conçues dans un souci d’accessibilité. "
Je pense que c'est un problème lié à un problème général. À la naissance de HTML, personne ne pouvait prévoir son utilisation généralisée. Une autre technologie qui s’est presque effondrée sous le poids de son propre succès. Lorsque les pages HTML étaient écrites en vi sur un terminal en texte en vert, il suffisait d'un TABLEAU pour présenter les données aux visiteurs de la page, et c'étaient principalement des données qui avaient un sens sous forme de tableau.
Nous savons tous comment les choses ont évolué. Les TABLE ont récemment cessé d'être à la mode, mais il existe de nombreuses raisons de préférer les dispositions DIV et CSS (l'accessibilité n'est pas la dernière). Bien sûr, je ne peux pas écrire de CSS pour sauver ma vie :-) et je pense qu'un expert en design graphique devrait toujours être à portée de main.
Cela dit ... il y a beaucoup de données qui devraient être présentées dans un tableau, même sur un site Web moderne.
Si vous appuyez l'angle de la table sur cette page, recherchez un site contenant des tables, puis procurez-vous un lecteur d'écran. Désactivez le lecteur d'écran et éteignez votre moniteur.
Ensuite, essayez-le avec un bon site de mise en page div sémantiquement correct.
Vous verrez la différence.
Les tableaux ne sont pas diaboliques si les données qu’ils contiennent ne sont pas tabulaires pour mettre en page la page.
Selon mes connaissances sur les tables, si trop de tables sont imbriquées, le rendu de la page par le navigateur est très lourd.
1 - Le navigateur a attendu que la vue finale soit restituée jusqu'à ce que toute la table soit chargée.
2 - L’algorithme de rendu de la table est coûteux et n’est pas instantané. Le navigateur, au fur et à mesure, récupère le contenu, essaiera de calculer la largeur et la hauteur du contenu. Donc, si vous avez des tables imbriquées, par exemple, le navigateur a reçu la première ligne et que la première cellule a un contenu important, et que la largeur et la hauteur ne sont pas définies, il calculera la largeur et rendra la première ligne. alors que la 2e rangée est occupée, la cellule 2 aura beaucoup de contenu! Il va maintenant calculer la largeur pour les cellules de la 2e rangée. Qu'en est-il de la première? Il calculera les largeurs de manière récursive. C'est mauvais du côté des clients. (Pour trouver un exemple.) En tant que programmeur, vous optimiserez les tâches telles que le temps nécessaire pour récupérer des données, des structures de données optimisées, etc. Vous optimisez les tâches à effectuer côté serveur, par exemple en 2 secondes, mais l'utilisateur final obtient la vue finale 8 secondes Qu'est-ce qui ne va pas ici? 1. Peut-être le réseau est lent! Et si le réseau est bon? Quel est le réseau fournit le contenu dans la prochaine 1 seconde? Où est-ce que 5 secondes supplémentaires sont consommés? Ce qui vous préoccupe - Le navigateur prend peut-être beaucoup de temps pour estimer et afficher les tableaux!
Comment optimiser les tables? À mon avis, si vous utilisez des tableaux, définissez toujours la largeur des cellules. Cela ne garantit pas que le navigateur prendra aveuglément cette largeur uniquement, mais cela aiderait beaucoup le navigateur à choisir les largeurs initiales.
Mais, à la fin, les div sont un excellent moyen car CSS peut être mis en cache par le navigateur; alors que la table n'est pas mise en cache!
Les tableaux utilisés en tant que disposition pure posent certains problèmes d'accessibilité (ce que j'ai entendu dire). Mais je comprends ce qui est demandé ici, à savoir que vous paralysiez le Web en utilisant un tableau pour assurer un alignement correct de quelque chose sur votre page.
J'ai déjà entendu des gens dire que les étiquettes et les entrées FORM sont en fait des données et qu'elles devraient être autorisées dans les tableaux.
L'argument voulant que l'utilisation d'une table pour s'assurer que quelques éléments soient correctement alignés provoque cette augmentation massive de code a tendance à inclure des exemples montrant comment une seule division virtuelle peut répondre à tous leurs besoins. Ils n'incluent pas toujours les 10 lignes de CSS et les hacks de navigateur spéciaux qu'ils ont dû écrire pour IE5, IE5.5, IE6, IE7 ...
Je pense qu'il reste à utiliser l'équilibre dans votre conception. Les tableaux sont dans la boîte à outils, rappelez-vous à quoi ils servent ...
Certes, le PO était un peu à l’état final, les arguments semblent si simples et facilement contrés.
Les pages Web sont le domaine des développeurs Web et s’ils disent que div et CSS sont meilleurs que les tableaux, c’est suffisant pour moi.
Si une mise en page est réalisée à l'aide de tables générées par une application serveur, une nouvelle mise en page signifie des modifications de l'application, une reconstruction et une redistribution de l'application, par opposition aux modifications apportées à un fichier CSS.
De plus, l'accessibilité. Les tableaux utilisés pour la mise en page rendent un site Web inaccessible, alors ne les utilisez pas. C'est une évidence, pour ne pas dire illégal.
Réponse très courte: la conception de sites Web maintenables est difficile avec des tableaux et simple avec la méthode standard pour le faire.
Un site Web n'est pas une table, c'est un ensemble de composants qui interagissent les uns avec les autres. Décrire cela comme une table n'a pas de sens.
En termes de maintenance du site et de révisions de la conception tout en conservant le contenu (ce qui arrive tout le temps, en particulier dans le commerce électronique):
Contenu et design mélangés via des tables = mettre à jour le contenu et le design.
Contenu séparé du design = mettre à jour le design et peut-être un peu de contenu.
Si je pouvais le faire à ma façon, je garderais mon contenu dans PHP en générant du XML, converti en balisage en XSLT et conçu avec CSS et Javascript pour l'interaction. Pour le côté Java, JSP à JSTL génère le balisage.
En utilisant DIV, vous pouvez facilement changer de choses. Par exemple, vous pourriez faire ceci:
Menu | Content
Content | Menu
Menu
----
Content
Il est facile de le changer en CSS, pas en HTML. Vous pouvez également fournir plusieurs styles (droitier, gaucher, spécial pour petit écran).
En CSS, vous pouvez également masquer le menu dans une feuille de style spéciale utilisée pour l’impression.
Une autre bonne chose est que votre contenu est toujours dans le même ordre dans le code (le menu en premier, le contenu après) même si visuellement il est présenté autrement.