Valider ? Pour quoi faire concrètement ?

Actualité par (Intégrateur du Dimanche, Strasbourg)
Créé le , mis à jour le (24130 lectures)

Si valider sa page web ne doit pas être un but, c'est souvent une étape primordiale pour éviter les problèmes d'affichages.

World Wide Web Consortium Suite à une question postée sur le forum Alsacréations et qui concernait un problème d'affichage (dixit : ma liste me fait sauter mon style appliqué a <p>. edit : en fait je veux faire une liste ds un p, ...) et où s'en suit un code HTML mal imbriqué, Laurent Denis nous gratifie d'une intervention à retenir.

En fait, sa réponse est suffisamment pertinente pour constituer à elle seule l'objet de ce billet :

Voilà une erreur (tout à fait compréhensible) très intéressante et très pédagogique.

En effet, en (X)HTML, les éléments <p> ne peuvent pas contenir de listes <ul>, lesquelles ne peuvent pas contenir directement des éléments <dl>, lesquelles ne peuvent pas contenir du texte anonyme. Et cette erreur de validité HTML conduit directement au problème CSS... alors que beaucoup de gens, volontairement ou involontairement, ne se soucient pas de réaliser d'abord un site valide avant de s'occuper de sa présentation...

En cas de problème de rendu, toujours commencer par vérifier la validité du code (X)HTML

Un code invalide sera traité par chaque navigateur selon ses propres processus de traitement d'erreur, potentiellement variables de l'un à l'autre, car ils ne sont soumis actuellement à aucune spécification : à moins d'avoir une parfaite connaissance de ces processus pour chaque navigateur (ce qui est en fait illusoire actuellement, même à un très haut niveau d'expertise), on s'en remet donc en quelque-sorte au hasard pour déterminer l'arbre du document, c'est à dire la structure finale réelle de son document telle que le navigateur va l'utiliser pour le rendre à l'écran avec CSS et le manipuler avec JavaScript. __ Les styles CSS, on l'ignore trop souvent, ne sont en effet pas appliqués au code HTML que vous avez écrit, mais au code tel qu'il a été interprété et corrigé par le navigateur, qui s'efforcera de rétablir un code valide et donc utilisable.__ Le résultat peut être très loin des attentes de l'auteur, comme c'est le cas ici.

Pour les curieux, un exemple : ici, IE, FF et Opera considèrent que le paragraphe se ferme avant l'ouverture de la liste <ul>, et insèrent une balise </p> avant le <ul>. Cette décision est logique dans la mesure où la balise de fermeture des paragraphes est optionnelle en HTML et où le document, même s'il est peut-être formellement en XHTML, est traité en tant que text/html. C'est d'ailleurs ce qui conduit ces trois navigateurs à adopter dans ce cas précis la même méthode de traitement de l'erreur, alors qu'ils auraient pu diverger.

Firefox traite de même la fermeture finale de paragraphe en la transformant en <p></p> vide. Opera, lui, fait directement disparaître le </p> et ne génère rien dans l'arbre du document à ce point. Je n'ai pas vérifié quel était le choix fait par IE, mais on peut noter au passage que, dans tous ces navigateurs, il est totalement inutile de mettre une liste <ul> dans un paragraphe puisque cette structure invalide est obligatoirement neutralisée en HTML et (X)HTML traité comme tel.

On se retrouve donc, au final, avec un premier paragraphe contenant du texte, suivi par une liste <ul> au contenu invalide, suivi par du texte anonyme (celui commençant par "Ainsi que tant d'autres hélas disparues..."), suivi éventuellement par un paragraphe vide.

Tout à fait logiquement, le contenu de <ul> et le texte anonyme ne peuvent pas être stylés par une règle p {...} comme l'auteur le souhaitait, puisqu'ils ne sont pas dans un <p> une fois le code corrigé par ces navigateurs.

On a donc structuré et stylé pour rien, sauf que le navigateur et l'auteur ont dû travailler un peu plus que si le code avait été valide. C'est un très bel exemple, très simple, de la nécessité constante de ne travailler que sur des structures valides... et donc prévisibles et faisant gagner du temps , ce qui est tout l'intérêt des standards Web ;)

(En passant, pour les vraiment très curieux, voir le récent billet de Yan Hyxon : Tag Soup: Crazy parsing adventures, particulièrement révélateur.)

Merci aux différents participants de cette discussion sur le forum Alsacréations  et plus particulièrement Laurent Denis

Retrouvez tous les participants au blog communautaire sur cette page dédiée.

Commentaires

CrystalGraph a dit le

Bel article sur la validation. Rendre valide c'est bien, mais XHTML c'est mieux.

Monique a dit le

> Les styles CSS, on l'ignore trop souvent, ne sont en effet pas appliqués au code HTML que vous avez écrit, mais au code tel qu'il a été interprété et corrigé par le navigateur, qui s'efforcera de rétablir un code valide et donc utilisable

Bonjour,

Je crois que ce passage devrait être mieux mis en évidence parce que ce mode de fonctionnement est vraiment très peu connu !

Amicalement,
Monique

QuentinC a dit le

Excellent exemple qui prouve une fois de plus qu'un code valide est primordial.

Bernard Pivot (encore lui !) a dit le

Concernant le titre de ce billet, il faut bien entendu écrire "Pour quoi" et non "Pourquoi". Puisqu'on ne s'intéresse pas ici aux causes mais à la finalité.

Felipe a dit le

Merci de la remarque Bernard :-)
Corrigé

clb56 a dit le

@ monique >
"
Je crois que ce passage devrait être mieux mis en évidence parce que ce mode de fonctionnement est vraiment très peu connu !
"
Il me semble que ce que l'article met très bien en évidence c'est qu'à partir du moment où l'on code de manière non valide on entre dans un domaine inconnu et plutôt aléatoire car sauf erreur les exemples donnés laissent ouvertes d'autres possibilités suivant d'autres agents utilisateurs des documents ainsi rédigés (codés).

TheRec a dit le

En même temps on peut difficilement écrire un article sur la validation et se permettre de ne pas avoir une page valide pour celui-ci ;)

Il ne faut également pas aller plus loin que le validateur CSS du W3C pour se rendre compte que la règle "En cas de problème de rendu, toujours commencer par vérifier la validité du code (X)HTML" ... Une syntaxe XHTML invalide rend impossible la validation d'une feuille CSS. Un petit exemple ici (l'erreur "Please, validate your XML document first!" sera affichée tant que cette même page sera invalide) :
jigsaw.w3.org/css-validat...

(Je suis conscient que maintenir un blog valide est difficile, mais l'erreur ne vient pas du billet en lui même, mais du lien ver le fil RSS des commentaires)

Laurent Denis a dit le

Une précision: l'invalidité XHTML peut en effet empêcher la validation CSS quand c'est l'url de la page (X)HTML qui est soumise au validateur. Elle n'a en revanche aucun effet lorsque le fichier CSS est directement soumis. Les deux procédures de validation CSS s'avèrent également employées par les auteurs...

Laurent Denis a dit le

Ah, une autre précision que j'oubliais : l'invalidité de cette page du blog Alsa pose un problème bien plus difficile : l'invalidité due à un prestataire externe, ou à un fournisseur de script. Voir www.temesis.com/publicati...

TheRec a dit le

En même temps le contexte évoqué implique bien que la feuille de style et le fichier sont bien liés, à moins que t'aie vu du XML dans une feuille de style récemment ;). Il m'est rarement arrivé de valider juste une feuille de style, enfin la précision aidera peut-être à la compréhension pour certains.

Concernant l'invalidité due à un prestataire externe, j'avais noté ce fait (dans mon premier message). Simplement il relève du choix du créateur d'un document d'utiliser ou non des services nécessitant des éléments non conformes. Si en l'occurence le prestataire (BlogMark) ne propose pas de solution conforme, pourquoi continuer à l'utiliser ?

TheRec a dit le

Je tiens tout de même à vous féliciter pour cette intervention enrichissante ! J'ai abordé le problème sous un angle critique de prime abord, et j'en ai oublié la politesse. Pardon.

Ju a dit le

"est traité en tant que text.html"

"text/html" plutôt non ?

Laurent Denis a dit le

@Ju : oui, bien-sûr. Merci de l'avoir signalé.

TestMan a dit le

En parlant de problèmes, l'inclusion des liens arrières gère mal l'utilisation d'un encodage de page différent (voir mon lien ci-dessus " de l'importance des standards). Dans le cas présent l'inclusion aurait dû convertir de charset source (UTF-8) à charset cible (latin-1).

Seb a dit le

Pour ma part j'utilise un méthode très simple qui me permet de connaitre la hiérarchie parent et enfant des balises html que je peux utiliser via ce site :

giminik.developpez.com/xh...

il est très bien pour apprendre à coder correctement et il évite les erreurs aussi ;)