Est-ce acceptable pour du XHTML invalide ?

Question

J'ai remarqué que de nombreux sites, y compris SO, utilisent XHTML comme langage de balisage et ne respectent pas les spécifications.Il suffit de parcourir la source pour trouver SO, il manque des balises de fermeture pour les paragraphes, des éléments invalides, etc.

Les outils (et les développeurs) devraient-ils donc utiliser le doctype XHTML s'ils veulent produire un balisage invalide ?Et les navigateurs devraient-ils être plus fermes dans leur acceptation d’un mauvais balisage ?

Et avant que quiconque crie à l'hypocrite, mon blog contient un élément de balisage invalide impliquant le captha (ou c'était le cas la dernière fois que j'ai vérifié) qui implique le style de la balise noscript.

Answer 1

Il y a de nombreuses raisons pour utiliser un balisage valide.Ce que je préfère, c'est qu'il vous permet d'utiliser la validation comme une forme de test de régression, empêchant l'équivalent du balisage "delta rot" d'entraîner de réels problèmes de rendu une fois que les erreurs atteignent une certaine masse critique.Et vraiment, c'est tout simplement bâclé de permettre aux erreurs « paresseuses » comme les fautes de frappe et les balises mal imbriquées/non fermées de s'accumuler.Un balisage valide est un moyen d'identifier programmeurs passionnés.

Il y a aussi le problème du débogage :un balisage valide vous donne également une base de référence stable à partir de laquelle travailler sur les inévitables problèmes de compatibilité entre navigateurs.Aucun développeur Web qui apprécie son temps ne devrait commencer à déboguer les problèmes de compatibilité du navigateur sans s'assurer au préalable que le balisage est au moins syntaxiquement valide - et tout autre balisage invalide devrait avoir une bonne raison d'être là.

(Soit dit en passant, stackoverflow.com échoue à ces deux tests et aux suggestions pour résoudre les problèmes. étaient diminué.)

Cela dit, pour répondre à votre question spécifique, cela ne vaut probablement pas la peine d'utiliser l'un des doctypes XHTML à moins que vous ne prévoyiez de produire des fichiers valides (ou à moins balisage bien formé).Les principaux avantages de XHTML découlent du fait que XHTML est XML, ce qui lui permet d'être traité et transformé par des outils et des technologies fonctionnant avec XML.Si vous ne prévoyez pas de créer du XML bien formé pour votre XHTML, cela ne sert à rien de choisir ce type de document.La dernière spécification HTML 4 fera probablement tout ce dont vous avez besoin, et elle est beaucoup plus indulgente.

Answer 2

Il faut toujours essayer de le faire valider selon les normes.Nous serons sûrs que le site Web s'affichera et fonctionnera correctement sur les navigateurs actuels ET futurs.

Answer 3

Je ne pense pas que si vous spécifiez un doctype, il y ait une raison de ne pas adhérer à ce doctype.

L'utilisation de XHTML facilite la détection automatisée des erreurs, chaque modification pouvant être automatiquement vérifiée pour détecter tout balisage non valide.Cela évite les erreurs, notamment lors de l’utilisation de contenu généré automatiquement.Il est très facile pour un développeur Web utilisant un moteur de création de modèles (JSP, ASP.NET StringTemplate, etc.) de copier/coller une balise de fermeture en trop petit ou en trop grand nombre.Lorsqu’il s’agit de votre seule erreur, elle peut être détectée et corrigée immédiatement.J'ai déjà travaillé pour un site qui contenait 165 erreurs de validation par page, dont 2 ou 3 étaient de véritables bugs.Il était difficile de les trouver parmi le fouillis d’autres erreurs.Une validation automatique aurait évité ces erreurs à la source.

Inutile de dire que choisir un standard et s'y tenir ne pourra jamais bénéficier de l'interopérabilité avec d'autres systèmes (grattoirs d'écran, lecteurs d'écran, moteurs de recherche) et je n'ai jamais rencontré de situation où une solution XHTML sémantique valide avec CSS n'était pas possible pour tous. principaux navigateurs.

Évidemment, lorsque vous travaillez avec des systèmes complexes, il n'est pas toujours possible de s'en tenir à votre doctype, mais cela est principalement dû à une mauvaise communication entre les différentes équipes développant différentes parties de ces systèmes, ou, plus probablement, des systèmes existants.Dans le dernier cas, il est probablement préférable d'isoler ces cas et de modifier votre doctype en conséquence.

Il est bon d'être pragmatique et de ne pas adhérer à XHTML simplement parce que quelqu'un l'a dit, quel que soit le coût, mais avec les connaissances actuelles sur CSS et les navigateurs, ainsi que sur les outils de test et de validation, les avantages sont la plupart du temps bien supérieurs aux coûts.

Answer 4

Vous pouvez dire que j'ai un TOC sur la validité XHTML.Je trouve que la plupart des problèmes liés à la non-validité du code proviennent du fait que les programmeurs ne connaissent pas la différence entre HTML et XHTML.J'écris du XHTML et du CSS 100% valides depuis un certain temps maintenant et je n'ai jamais eu de problèmes de rendu majeurs avec d'autres navigateurs.Si vous gardez tout valide et n'essayez rien de trop exotique en termes de CSS, vous vous épargnerez une tonne de temps en correctifs.

Answer 5

Je n'utiliserais pas du tout XHTML juste pour m'épargner le stress philosophique.De toute façon, ce n'est pas comme si les navigateurs le traitaient comme du XHTML.

Les navigateurs rejetteront un mauvais balisage si la page est envoyée sous la forme application/xhtml+xml, mais ils le font rarement.C'est bon.

Je serais plus préoccupé par des choses comme l'utilisation en ligne de CSS et JavaScript avec Stack Overflow, simplement parce qu'elles rendent la maintenance plus difficile.

Answer 6

Même si je crois à la nécessité de rechercher des XHTML et CSS valides, c'est souvent difficile à réaliser pour plusieurs raisons.

• Premièrement, une partie du contenu pourrait être chargée via AJAX.Parfois, les fragments ne sont pas correctement insérés dans le DOM existant.
• Les fichiers HTML que vous consultez n'ont peut-être pas tous été produits dans le même document.Par exemple, la page peut être composée de composants ou de modèles, puis assemblée juste avant que le navigateur ne la restitue.Ce n’est pas une excuse, mais vous ne pouvez pas supposer que le code HTML que vous voyez a été codé manuellement en une seule fois.
• Que se passe-t-il si une partie du code généré par Markdown n'est pas valide ?Vous ne pouvez pas reprocher à Stack Overflow de ne pas produire de code valide.
• Enfin, le but du DOCTYPE n'est pas simplement de dire "Hé, j'utilise du code valide", mais c'est aussi de donner au navigateur une idée de ce que vous essayez de faire afin qu'il puisse au moins se rapprocher d'une analyse correcte. ces informations.

Je ne pense pas que la plupart des développeurs spécifient un DOCTYPE et ne parviennent pas explicitement à y adhérer.

Answer 7

bien que je sois d'accord avec le sentiment de « si le rendu est correct, ne vous inquiétez pas », il est cependant bon de suivre une norme, même si elle n'est peut-être pas entièrement prise en charge pour le moment.vous pouvez toujours utiliser Table pour la mise en page, mais ce n'est pas bon pour une raison.

Answer 8

Non, vous ne devez pas utiliser XHTML si vous ne pouvez pas garantir la bonne forme, et en pratique, vous ne pouvez pas le garantir si vous n'utilisez pas de sérialiseur XML pour générer du balisage.Lire à propos de la production de XML.

La bonne formation est le chose qui différencie le XHTML du HTML.Le XHTML avec « une juste » erreur de balisage cesse d'être du XHTML. Il faut que ce soit parfait à chaque fois.

Si le site "XHTML" semble fonctionner avec quelques erreurs, c'est parce que les navigateurs ignorent le DOCTYPE et interpréter la page au format HTML.

Voir proxy XHTML cela force l'interprétation des pages en XHTML.La plupart du temps ils échouent lamentablement.C'est l'une des raisons pour lesquelles l'avenir du XHTML est incertain et pourquoi le développement du HTML a repris.

Answer 9

Ça dépend.j'avais ça problème avec mon blog où une vidéo YouTube provoquait un XHTML invalide, mais le rendu était correct.D'un autre côté, j'ai un lien "XHTML valide", et une combinaison d'une réclamation "XHTML valide" et d'un XHTML invalide n'est pas professionnelle.

Comme SO ne prétend pas être valide, je pense que c'est acceptable, mais personnellement, si j'étais Jeff, cela me dérangerait et j'essaierais de le réparer même si cela semble bien dans les navigateurs modernes, mais certaines personnes préfèrent simplement passer à autre chose et faire avancer les choses. au lieu de corriger des bugs inexistants.

Answer 10

Tant que cela fonctionne dans IE, FF, Safari (insérez un autre navigateur ici), tout devrait bien se passer.La validation n'est pas aussi importante que de l'afficher correctement dans plusieurs navigateurs.Ce n’est pas parce qu’il est valide que cela fonctionnera correctement dans IE, par exemple.

Exécutez Google Analytics ou similaire sur votre site et voyez quel type de navigateurs vos utilisateurs utilisent, puis jugez quels navigateurs vous devez le plus prendre en charge et souciez-vous des moins importants lorsque vous avez le temps libre pour le faire.

Answer 11

Je dis que si le rendu est correct, peu importe que le pixel soit parfait.

Il faut un certain temps pour qu'un site soit opérationnel comme vous le souhaitez, revenir en arrière et apporter des modifications modifiera légèrement la façon dont la page s'affiche, vous devrez alors corriger ceux problèmes.

Maintenant, je ne dis pas que vous devriez créer des pages Web bâclées, mais je ne vois aucune raison de réparer ce qui n'est pas cassé.Les navigateurs ne vont pas abandonner la prise en charge de la correction d’erreurs dans un avenir proche.

Answer 12

Je ne comprends pas pourquoi tout le monde s'efforce d'adapter ses sites Web à la norme alors que certains navigateurs ont toujours des problèmes pour restituer correctement le code standard.Je suis dans la conception de sites Web depuis environ 10 ans et j'ai arrêté le double codage (lire :pirater du CSS), et changer des trucs stupides juste pour pouvoir mettre un bouton sur mon site.

Je crois que l'utilisation d'un <div> vous rendra invalide de toute façon, et il deviendra un peu plus difficile de faire du JavaScript/AJAX majeur sans cela.

Answer 13

Il existe tellement de normes et elles sont si mal « appliquées » ou prises en charge que je ne pense pas que cela ait de l'importance.Ne vous méprenez pas, je pense qu'il devrait y avoir des normes, mais comme elles ne sont pas appliquées, personne ne les respecte et c'est une énorme spirale descendante.

Answer 14

Pour 99,999 % des sites, cela n'a vraiment pas d'importance.La seule fois où cela m'a posé problème, j'ai exécuté l'entrée HTML via HTMLTidy pour la transformer en XHTML, puis j'ai exécuté mon traitement dessus.

C'est à peu près l'axiome du vieux programmeur :ne faites confiance à aucune contribution.