Valider ? Pour quoi faire concrètement ?

Actualité

Publié par le , mis à jour le (28119 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

> 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

@ 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).

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)

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...

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 ?

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.

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).

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 ;)

Commentaires clos