Doctype : comment démontrer que son choix est important ?

Bonjour

Ayant besoin d'expliquer l'importance du Doctype dans une page web, j'ai créé 1 page (mal codé) avec un DTD Xhtml 1.0 strict et je l'ai dupliqué en supprimant le DTD en espérant avoir un rendu visuel différent.
La différence n'est pas probante malgré mon acharnement à mettre des majuscules, enlever les guillemets et autres atrocités...
Page test avec DTD : http://www.reflet-web.com/test/test.html
Page test sans DTD : http://www.reflet-web.com/test/test_sans_doctype.html

Ma démarche est-elle inutile, mon code trop simple et existe t-il une spécificité d'Xhtml qui me permettrait d'avoir un rendu visuel vraiment différent ?

Merci

Hello,

Si tu fais une page à base de tableaux, éléments FONT et autres joyeusetés, en utilisant peu/pas les CSS, tu n'aurais pas de grandes différences, effectivement.

cilou a écrit :
malgré mon acharnement à mettre des majuscules

Le fait que les noms d'éléments et d'attributs soient écrits en minuscules ou majuscules ne perturbe pas les navigateurs.

cilou a écrit :
enlever les guillemets

Cela n'a un impact que si tu as des valeurs avec des espaces pour tes attributs. Par exemple:

<p class="class1 class2 class3">...</p>
<p class=class1 class2 class3>...</p>

La deuxième ligne sera mal interprétée par les navigateurs (enfin, bien interprétée, mais elle est mal écrite à la base...).

cilou a écrit :
existe t-il une spécificité d'Xhtml qui me permettrait d'avoir un rendu visuel vraiment différent ?

Même si tes pages utilisent la syntaxe XHTML, elles sont analysées comme du HTML par les navigateurs. Si tu veux qu'elles soient analysées comme un dialecte de XML, il faut envoyer tes pages avec le type MIME "application/xhtml+xml" et non pas le typte MIME "text/html".

En général, on s'en tient plutôt au type MIME "text/html", plus compatible avec les différents navigateurs.

Merci Florent

J'avais bien lu le tutoriel sur les DTD où il est expliqué que les navigateurs ne s'en servent pas pour déchiffrer le code mais je pensais "naïvement" qu'en strict j'aurai au moins une différence visuelle (couleur ou positionnement)... même l'oubli d'une balise de fermeture de paragraphe passe allègrement . Comment expliquer à quelqu'un, fier de son site en tableau avec un code "tout bazar" et un DTD incomplet qu'il est dans l'erreur si, en rajoutant un Doctype strict, le résultat visuel est le même... (argumenter avec Tidy ou le validateur W3C... c'est trop complexe, quand à changer le type MIME, ça fausse la donne je trouve)

Lui montrer le résultat sur IE6 (qui doit, dès lors, passer en mode Quircks) puis lui donner un aperçu du résultat avec les styles et les images désactivés.

Les modes "quirks" ou "almost standard" servent justement à rattraper les erreurs. Tu ne peux donc pas - ou du moins pas si facilement - obtenir de grosses différences visibles sur des erreurs syntaxiques légères comme tu l'as tenté, parce précisément les navigateurs sont conçus pour les gommer. Le jour où les développeurs arrêteront d'implémenter les "quirks" (c'était un temps en projet pour IE8) là je te garantis que ça va le faire ! C'est d'ailleurs une des causes pour laquelle MS est revenu appremment en arrière : un IE8 non-quirksé aurait été incapable d'afficher correctement 95% des sites web actuels mal codés ; du coup l'internaute lambda se serait dit que cet IE8 c'est de la daube, alors que pour une fois il n'y est pour rien.
La responsabilité des éditeurs de navigateurs est engagée puisqu'en ne respectant pas les specs W3C les concernant ils ont de fait permis la possibilité à des millions de pages mal codées de rester affichables et utilisables. La preuve : ton test non-probant.
Ça ne démontre pas pour autant l'inutilité des standards, bien au contraire : plus il y aura de sites normés et moins l'obligation de "quirkser" les versions futures des navigateurs s'imposera. Pour les équipes de dév ça représente du temps, de l'argent et de l'énergie inutilement dépensés. Du coup, dans quelques années et d'ici quelques versions, les modes "quirks" et "almost" ayant disparu seuls les sites normés seront affichables, consultables et utilisables. Alors autant s'y mettre tout de suite

Merci Cygnus et Arsene.
Je comprends bien qu'un site mal codé avec un DTD erroné passe en mode quirks ou almost standard (effectivement "préférable" pour pouvoir naviguer actuellement), je comprend moins qu'avec un DTD correct, le navigateur passe aussi dans ces modes là. Ma conclusion, au vu du test avec le DTD strict, c'est que FF à "lu" mon DTD (enfin, j'espère qu'il n'était pas faux) et qu'un fois arrivé dans le code, il s'est dit "oulala le bazar, je passe en mode almost standard pour afficher la page"... je trouve que c'est frustant
C'est vrai que mon code est simpliste... je vais tacher de le complexifier !
Sinon, je suis d'accord avec toi, Arsene, autant travailler proprement dans l'espoir d'un futur plus rigoureux.

cilou a écrit :
Ma conclusion, au vu du test avec le DTD strict, c'est que FF à "lu" mon DTD (enfin, j'espère qu'il n'était pas faux) et qu'un fois arrivé dans le code, il s'est dit "oulala le bazar, je passe en mode almost standard pour afficher la page"...

Non: il affiche la page en mode Standard, mais même dans ce mode il fait son possible pour rattraper les erreurs des petits saligauds qui codent n'importe comment.

Franchement, je ne vois pas où est le problème. C'est une qualité des navigateurs que d'effectuer ce boulot de rattrapage. Du coup l'intérêt d'un code valide est subtil: un code invalide peut passer sans problème, mais c'est prendre un risque inutile. Une seule erreur peut demander des dizaines de minutes de recherche pour trouver la source du problème. Si le code contient de nombreuses erreurs, il faudra beaucoup de travail pour trouver l'erreur (parmi les 15 ou 100 ou 500...) que le navigateur n'arrive pas à rattraper.

Tu n'as pas besoin d'une explosion atomique pour démontrer les dangers d'un code invalide. Le web est une industrie avec des standards industriels. Si un de tes collaborateurs préfère le bricolage, eh bien change de collaborateur.