[Validations W3C] Incompréhension

bonjour à tous Alsacréateurs

Je cherche à faire valider mon site aux normes W3C. J'ai donc pour commencer fais tester la home http://belle.kawax.com/index.php?page=1 je vois 13 erreur. J'en corrige 4, et là attention, surprise, il m'en reste 9 !!

*** lien trop long qui déforme le forum, corrigé par le modérateur ***

Voila, je compte sur vos éclaircissements pour me remonter de ces profondeurs infernales du PHP dans lesquelles je me suis lamentablement ramassé...

Merci à vous
Modifié par Florent V. (11 Sep 2007 - 21:19)

Alors, avec Validome comme présenté en post-it j'ai pu comprendre de quoi il s'agissait.

Par contre, Validome me vois plus d'erreur que le W3C validator

Par exemple :


<br /> est reconnu comme un erreur sur Validome à l'inverse de W3C Validator...

C'est bizarre, pourtant le même encodage est selectionné

J'ai toujours des erreur dans les pages 2,3,4...

Assez incompréhensibles parfois ?
Modifié par bluelight (11 Sep 2007 - 19:45)

bluelight a écrit :
Par exemple :
<br /> est reconnu comme un erreur sur Validome à l'inverse de W3C Validator...

Que <br /> (syntaxe XHTML) soit reconnu comme erreur pour une page déclarée comme du HTML 4.01, c'est plutôt normal. Si le validateur du W3C passe outre, par contre, c'est moins logique.

Au passage: tu utilises un Doctype HTML 4.01 Transitional dans sa forme tronquée (sans URL de la DTD), ce qui fera passer Internet Explorer en mode Quirks (pas forcément un bon plan).

bluelight a écrit :
J'ai toujours des erreur dans les pages 2,3,4...

Assez incompréhensibles parfois ?

Un bout de code qui renvoie une erreur:

<span style="text-align: center;">[#red]<hr width="200">[/#] <br><span class="strong">SESAME, ouvre toi !</span></span>

HR est un élément de type bloc. SPAN est un élément de type en-ligne. Les éléments de type en-ligne ne peuvent pas contenir des éléments de type bloc.

Utilise plutôt des paragraphes (P) pour structurer ton texte, et si besoin des lignes séparatrices (HR).

Heu... sinon, c'est un peu étrange de s'occuper de validation HTML quand pour un site «à l'ancienne»: rendu en mode Quirks plutôt qu'en mode Standard (car Doctype tronqué), utilisation allègre de <font>, tableaux de mise en page dans tous les sens, absence de balisage sémantique...
Je crois que deux ou trois (ou quinze) erreurs de validation sur des points un peu stricts de syntaxe HTML n'y changeront pas grand chose.

Peut-être l'occasion de se mettre au balisage sémantique, à XHTML (principalement pour l'avantage pédagogique dû à la rigueur de la syntaxe), et à une utilisation un peu plus importante des CSS?
(Après tout, Alsacréations est un site/forum qui traite précisément de ces sujets...)

Merci de tes réponses

Justement, je reprend un peu le code de l'ancienne versions du site, mais quelque peu modifiées. Je n'ose pas utiliser plus de CSS, dois-je alors ?

Comme je dois mettre le site en ligne dans 15 jours, je n'aurai pas le temps de m'occuper de la refonte totale du code. Ce sera pour l'année prochaine

Je n'utilisais pas de DTD complet car j'avais plein d'erreur CSS, corrigé depuis.... ce soir

@+

bluelight a écrit :
Je n'ose pas utiliser plus de CSS, dois-je alors ?

Le site mériterait une refonte. Là, les différents éléments ne sont pas bien identifiés et séparés les uns des autres (des span et font qui courent sur plusieurs lignes, des br partout...), donc appliquer du code CSS à tout ça risque d'être difficile.
Là tout de suite je ne vois pas trop l'intérêt d'utiliser du CSS juste pour utiliser du CSS. Si on n'est pas sur une base HTML saine, il n'y a pas grand chose à faire...

bluelight a écrit :
Comme je dois mettre le site en ligne dans 15 jours, je n'aurai pas le temps de m'occuper de la refonte totale du code. Ce sera pour l'année prochaine

Dommage pour l'année à venir, alors. Ça mériterait une refonte plutôt qu'un coup de pinceau.

Ouaip ok, j'avoue que je m'y suis assez mal pris, pris par le temps (si si). Mais bon, pour l'instant, si ça peut tenir comme ça, niveau utilisateur, ça roule, ça tient (je sais résonnement bete mais quand on a rien, on fait avec ).

Je suis encore en petite école (collège) donc en ce moment plus trop le temps

Florent V. a écrit :

Que <br /> (syntaxe XHTML) soit reconnu comme erreur pour une page déclarée comme du HTML 4.01, c'est plutôt normal. Si le validateur du W3C passe outre, par contre, c'est moins logique.

Non, c'est le validome qui ne gère apparement pas tt les fonctionnalités du SGML. <br /> pour un parser SGML équivaut en faite à <br> plus > (Null End Tags), c'est d'ailleurs une des raisons des critiques sur le "xHTML compatible".
Modifié par JyuniX (13 Sep 2007 - 16:29)

JyuniX a écrit :
Non, c'est le validome qui ne gère apparement pas tt les fonctionnalités du SGML. <br /> pour un parser SGML équivaut en faite à <br> plus > (Null End Tags), c'est d'ailleurs une des raisons des critiques sur le "xHTML compatible".

Oui, enfin aucun navigateur ne l'interprète comme tel à ma connaissance (et heureusement). Je ne comprends pas que le validateur du W3C n'affiche pas un warning dans ce cas.

a écrit :
Oui, enfin aucun navigateur ne l'interprète comme tel à ma connaissance (et heureusement).

Ils pourraient très bien le faire, c'est pourquoi je préfère personnelement coder toujours en HTML 4.01 qu'en xHTML pseudo-compatible (et jne suis pas le seul).

Sinon pourquoi tu veux qu'il t'affiche un warning ?
Modifié par JyuniX (13 Sep 2007 - 18:59)

JyuniX a écrit :
Ils pourraient très bien le faire

Il faut être un peu réaliste quand même.

Les navigateurs utilisent un parseur unique pour les documents servis en tant que text/html.

JyuniX a écrit :
Sinon pourquoi tu veux qu'il t'affiche un warning ?

Ben... Tout simplement parce que c'est une fonctionnalité de SGML qui n'est implémentée par aucun navigateur, et que ça porte à confusion...

C'est plus correct selon moi de créer un document HTML qu'un document xHTML déguisé en HTML qui n'est pas totalement compatible même en suivant les règles de l'appendix C. C'est donc plus une histoire de principe que d'avantage dans les faits je l'avoue.

Pour le warning, je pense qu'un validateur ne doit pas se fier aux tendances actuelles mais aux normes.

Julien Royer a écrit :

Oui, enfin aucun navigateur ne l'interprète comme tel à ma connaissance (et heureusement). Je ne comprends pas que le validateur du W3C n'affiche pas un warning dans ce cas.

JyuniX a écrit :


Non, c'est le validome qui ne gère apparement pas tt les fonctionnalités du SGML.

Ce n'est pas tout à fait cela.

La différence de comportement entre ces deux validateurs est tout à fait normale. Elle tient à leurs principes de conception.
- Le validateur du W3C est un validateur strictement basé sur SGML et les DTD. En un sens, c'est le plus "formaliste" des validateurs... mais aussi le plus limité quant aux nombreuses contraintes HTML non exprimables dans la DTD.
- Validome repose sur la DTD SGML pour HTML (et gère très bien toutes les fonctionnalités du SGML), mais réalise également des tests au-delà du SGML "formel". C'est le plus "explicite" des validateurs, mais aussi le plus flou en un sens. Il est d'ailleurs difficile de savoir exactement ce qu'il fait et comment, faute de documentation public et/ou de code libre.

Plus généralement, depuis HTML+ en 1993, HTML a défini successivement différentes variante de ses rapports avec SGML, dont le trait commun est d'être plutôt "embarrassées" : en résumé, HTML est globalement conçu comme une application de SGML, mais le fait que les agents utilisateurs ne soient pas conformes à SGML a toujours été reconnu par les spécifications. En fait, le validateur du W3C est un des rarissimes agents utilisateurs HTML qui traite réellement HTML en tant que SGML.

Au bout du compte, et conformément aux premiers essais de TBL, HTML n'a jamais été que "inspiré par SGML", en dépit de la tentation historique de le formaliser en tant qu'application de SGML. Le draft HTML5 en a d'ailleurs tiré la leçon.

<edit>Qu'aurait été HTML sans Raggett et Connolly ? That's the question </>
Modifié par Laurent Denis (15 Sep 2007 - 10:08)

JyuniX a écrit :
C'est plus correct selon moi de créer un document HTML qu'un document xHTML déguisé en HTML qui n'est pas totalement compatible même en suivant les règles de l'appendix C. C'est donc plus une histoire de principe que d'avantage dans les faits je l'avoue.

C'est justement au-delà du principe, et dans les faits, qu'XHTML1.0 a montré ses avantages par rapport à HTML4 : du point de vue du contexte de production (éditorial, CMS, etc), disposer de règles syntaxiques simples (parce que plus strictes) diminue les coûts. In the real life, les critiques théoriques (et fondées) sur l'appendice C n'ont aucune portée.
Modifié par Laurent Denis (15 Sep 2007 - 09:12)

Merci pour l'explication, Laurent.

Effet de bord amusant de cette histoire :

<title></title>
<hr />

Le validateur du W3C valide cette page avec le doctype HTML 4 transitional mais pas avec le strict.

Exeemple trouvé dans un article très intéressant (en anglais).
Modifié par Julien Royer (17 Sep 2007 - 11:46)

Un extrait du doctype transi :

<!ELEMENT BODY O O (%flow;)* +(INS|DEL) -- document body -->

Un extrait du doctype strict :

<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body -->

Les documents Transi acceptent des éléments inlines et donc du texte dans l'élément body tandis que les Strict n'acceptent que des éléments bloc.
Vu que <hr /> en HTML équivaut à faire <hr>>, c'est pourquoi ce code est valide en Transi et non en Strict.

Enfin je ne t'apprends probablement rien, je fais que traduire je suppose.

Sinon Laurent, tu ne trouves pas que c'est un peu court comme argument ? Syntaxe plus stricte alors qu'on peut avoir la même rigueur en HTML ?

Ce n'est pas qu'il diminue les coûts, c'est que c'est une bonne pub dans certains domaines. "Achetez ce CMS léger en xHTML et CSS"
Modifié par JyuniX (17 Sep 2007 - 22:57)

JyuniX a écrit :
Syntaxe plus stricte alors qu'on peut avoir la même rigueur en HTML ?

Hmm... tout est dans le mot en gras.

JyuniX a écrit :
c'est que c'est une bonne pub dans certains domaines. "Achetez ce CMS léger en xHTML et CSS"

Un peu de marketing ne fait pas de mal non plus.

On ne peut pas coder n'importe comment en xHTML peut-être ? Même moteur, même permissivité.

Un peu de marketing certes ne fait pas de mal mais prendre les gens pour des pigeons en leur racontant des bobards si jtrouve ça mauvais.
Modifié par JyuniX (18 Sep 2007 - 18:06)