Je vais parcourir vos arguments l'un après l'autre, et essayer de montrer les erreurs.
Il est bon de séparer le contenu de la mise en page
Mais c'est un argument fallacieux; Cliché de la Pensée.
C'est pas faux du tout parce que le HTML a été conçu intentionnellement. La mauvaise utilisation d'un élément peut ne pas être complètement hors de question (après tout, les nouveaux idiomes ont développé dans d'autres langues, aussi), mais éventuelles conséquences négatives être compensé. En outre, même s'il n'y avait pas d'arguments contre l'utilisation abusive de l' <table> élément d'aujourd'hui, il y a peut-être demain en raison de la façon dont les fournisseurs de navigateur appliquer un traitement spécial à l'élément. Après tout, ils savent que "<table> des éléments sont pour les données tabulaires" et pourrait utiliser ce fait pour améliorer le moteur de rendu, dans le processus subtilement changer la façon dont <table>s se comportent, et de rompre ainsi les cas où il a été précédemment utilisée à mauvais escient.
Et alors? Est-ce que mon patron soins? Faire mes utilisateurs de soins?
Dépend. Est votre patron pointu à poil? Puis, il pourrait ne pas s'occuper. Si elle est compétente, elle prendra soin, parce que les utilisateurs vont.
Peut-être que moi ou mes collègues développeurs qui ont à maintenir une page web de soins de... Est un tableau moins maintenable? Je pense que l'utilisation d'un tableau est plus facile que d'utiliser des divs et css.
La majorité des professionnels du web développeurs semblent s'opposer à vous[citation nécessaire]. Que les tables sont en fait moins maintenable devrait être évident. À l'aide de tableaux de mise en page signifie que la modification de la disposition de l'entreprise sera, en fait, signifie change à chaque page. Cela peut être très coûteux. D'autre part, l'usage judicieux du point de vue sémantique significative HTML combiné avec le CSS pourrait limiter de tels changements sur le CSS et les images utilisées.
Au fait... pourquoi utiliser un div ou span bonne séparation du contenu et de la mise en page et une table non? L'obtention d'une bonne mise en page avec seulement divs requiert souvent beaucoup de divs imbriqués.
Profondément imbriqués <div>s sont un anti-modèle tout comme les tableaux. Bon sur le web les concepteurs n'ont pas besoin de beaucoup d'entre eux. D'autre part, même profondément imbriqués les divs ne dispose pas de beaucoup de les problèmes des dispositions de table. En fait, ils peuvent même contribuer à une structure sémantique par logiquement divisant le contenu dans les pièces.
La lisibilité du code
Je pense que c'est l'inverse. La plupart des gens comprennent le html, peu de comprendre le css. C'est plus simple.
"La plupart des gens n'ont pas d'importance. Les professionnels de la question. Pour les professionnels, les dispositions de table créer beaucoup plus de problèmes que d'en HTML + CSS. C'est comme dire que je ne devrais pas utiliser GVim ou Emacs parce que le bloc-notes est plus simple pour la plupart des gens. Ou que je ne devrais pas utiliser LaTeX parce que MS Word est plus simple pour la plupart des gens.
C'est mieux pour le RÉFÉRENCEMENT de ne pas utiliser les tables
Je ne sais pas si cela est vrai et ne pas l'utiliser comme un argument, mais il serait logique. Les moteurs de recherche de recherche pour pertinente des données. Alors que les tableaux de données pourrait être pertinent, c'est rarement ce que l'utilisateur recherche. Utilisateurs de rechercher des termes utilisés dans le titre de la page ou de même des postes importants. Il serait donc logique d'exclure de tableaux de contenu de filtrage et donc de la coupe de la durée de traitement (et de prix!) par un grand facteur.
Les Tables sont plus lents.
Un supplément tbody élément doit être inséré. C'est peanuts pour les navigateurs web modernes.
L'élément supplémentaire n'a rien à voir avec des tables est plus lent. D'autre part, l'algorithme de mise en page pour les tableaux est beaucoup plus difficile, le navigateur doit souvent attendre pour l'ensemble du tableau à la charge avant de commencer à disposition le contenu. En outre, la mise en cache de la mise en page ne fonctionne pas (CSS peuvent facilement être mis en cache). Tout cela a été mentionné auparavant.
Montrez-moi quelques repères où l'utilisation d'une table ralentit considérablement d'une page.
Malheureusement, je n'ai pas de données de référence. Je serais intéressé par 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 nécessaire un nouveau contenu (html). Les scénarios où une nouvelle version d'un site web seulement besoin d'un nouveau fichier css ne sont pas très probable.
Pas du tout. J'ai travaillé sur plusieurs cas où la modification de la conception a été simplifiée par une séparation du contenu et de la conception. C'est encore souvent nécessaire pour changer un code HTML mais les changements seront toujours beaucoup plus confinés. En outre, les modifications de conception doit parfois être fait dynamiquement. Envisager de moteurs de template comme celui utilisé par le système de blogging WordPress. Des dispositions de Table serait littéralement tuer ce système. J'ai travaillé sur un cas similaire pour un logiciel commercial. Être en mesure de modifier la conception sans modifier le code HTML a été l'un des besoins de l'entreprise.
Un autre chose. La disposition de Table automatisés d'analyse de sites web (capture d'écran) beaucoup plus difficile. Cela peut sembler trivial, car, après tout, qui est-il? J'ai été surpris moi-même. Capture d'écran peut aider beaucoup si le service en question n'offre pas un Service alternatif pour accéder à ses données. Je travaille en bio-informatique, où c'est une triste réalité. Modernes techniques du web et de Services web n'ont pas atteint la plupart des développeurs et souvent, capture d'écran est le seul moyen d'automatiser le processus d'obtention des données. Pas étonnant que de nombreux biologistes toujours effectuer ces tâches manuellement. Pour les milliers de jeux de données.
