WordPress n’aime pas le web sémantique

Depuis la naissance du HTML, une certaine quantité de balises sémantiques avaient été prévues. Cela permettait aux différents logiciels, qui ont à traiter le HTML en question, de repérer la nature exacte des données traitées et d’ainsi améliorer très nettement l’accessibilité d’un contenu codé en HTML et de spécifier ainsi l’usage qui peut en être fait. Je dis bien ‘repérer la nature du contenu’ et non ‘le sens du contenu’ comme pourrait l’indiquer l’expression « web sémantique« .

Prenons un exemple :

<h1>Titre de niveau</h1>
<h2>Titre de niveau 2</h2>
<blockquote>Tant va la cruche à l'eau qu'à la fin wpautop me les brise !</blockquote>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur id
neque ac libero vehicula mattis. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Sed sit amet.</p>

On a donc plusieurs balises qui accompagnent et précisent la nature du contenu :

• h1 : Titre de niveau un (gros titre quoi…)
• h2 : Titre de niveau deux (moins gros titre…)
• blockquote : Citation
• p : Paragraphe

On peut tout à fait reproduire exactement le même affichage avec le HTML suivant :

<span class= ‘titre1’>Titre de niveau </span><br/>
<span class= ‘titre2’>Titre de niveau 2</span><br/>
<span class= ‘citation’>citation</span><br/>
<span class= ‘paragraphe’>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Curabitur id neque ac libero vehicula mattis. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Sed sit amet.</span>

On voit que toutes les balises relatives au web sémantique ont été remplacées par des balises ‘span’ auxquelles on attribue des classes CSS. L’affichage, après définition des classes CSS ‘titre1’, ’titre2’, ’citation’ et ‘paragraphe’ utilisées dans le HTML, sera tout à fait identique dans les deux cas.

Alors où est le problème…

• Il ne sera jamais admis par un perfectionniste, même moyen, que ce code est propre.
• Si on veut aller vers le web sémantique, il faut bien s’y mettre et exploiter les outils proposés dans ce cadre.
• Le standard ce n’est pas pour les chiens (sauf chez cro$oft).
• A vous de juger si l’accessibilité de votre site est importante ou pas.
• Il est très utile pour le référencement de permettre aux robots d’indexation de repérer la natures des éléments qu’ils digèrent.

Le rapport avec WordPress ?… Il n’est pas direct. Il découle plutôt d’un dysfonctionnement (c.f. ticket #3833 du trac de WordPress) de la fonction wpautop. Cette fonction permet de soulager l’auteur d’un poste des insertions rébarbatives de code HTML lors de la saisie. Plus précisément cette fonction est appliquée comme un filtre à l’affichage du contenu d’un poste ou d’un commentaire, lors de son envoi vers le client de l’internaute (lors de la requête HTTP correspondante). Ce qui signifie que cette fonction n’est pas appelée au moment de la sauvegarde du poste ou du commentaire, car après vérification dans la base de données, les données y sont conservées telles qu’elles ont été saisies.

Wpautop est une fonction très précieuse dans une majorité écrasante des cas. Mais quand elle délire, cela implique du code HTML non valide. Dans mon cas précis, wpautop ajoute systématiquement une balise ‘p’ fermante (</p>) juste avant mes balises ‘blockquote’ fermantes (</blockquote>). Par exemple quand j’ai dans la base de données ce qui suit pour un poste donné :

<blockquote>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</blockquote>

Wpautop m’en fait ce qui suit :

<blockquote>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p></blockquote>

Bien entendu cela n’est pas conforme aux spécifications W3C. Bien entendu il faut trouver une solution. Je me suis donc documenté, j’ai cherché sur le web une solution pérenne, conforme au standard et optimisée ! Pas gagné quoi …

Sachant que lors de la définition de mes CSS je partais du principe que la fonction wpautop était exempte de bug, j’ai défini un CSS pour les balises ‘p’ dans le contexte d’un poste et/ou d’un commentaire. Donc j’ai besoin de wpautop pour mettre en œuvre mes CSS. De plus il est très confortable de ne pas devoir ajouter des ‘div’ ou des ‘p’ au code HTML, l’idéal étant de ne recourir qu’à l’interface de saisie WYSIWYG. Du moins dans la mesure du possible et le moins souvent possible. Autrement la saisie d’un poste devient un chantier HTML très chronophage. Et puis zut alors, moi j’ai joué le jeu j’ai défini des CSS pour tout et je tiens à l’optimisation du code et au respect du standard… Alors ! Donc la solution qui consiste à utiliser une extension WordPress pour désactiver le fonctionnement du CSS n’est pas envisageable pour moi.

Me reste deux possibilités. Soit hacker le code du fichier contenant la définition de la fonction ‘wpautop’ (wp-includes/formatting.php), donc taper directement dans le code de WordPress. Ou encore taper directement dans le code javascript quicktags.js (d’après une page web un utilisateur a réglé son problème par là. Mais il n’était jamais revenu sur le forum en question partager sa solution. Je crois avoir compris comment il a œuvré, mais je déteste le javascript et la solution est un brin sauvage !). Quoiqu’il en soit ce sont deux solutions qui ne sont pas satisfaisantes. Effectivement hacker le code implique que lors d’une mise à jour il faut le rehacker. Mais le plus inquiétant c’est qu’il vaut mieux éviter de trifouiller un code source d’une application car en l’occurrence on ne sait pas quels seraient exactement l’impact de la modification étant donné qu’on ne maîtrise pas tous les usages fait de ce code justement ! Pas top quoi…

Alors j’ai fait comment ?… J’ai fait l’impasse sur le web sémantique et franchement j’assume mal. J’ai honte… Mais ne vous inquiétez pas on s’y fait. Toutes mes balises ‘blockquote’ ont été remplacées par des balises ‘div’ avec la class CSS qui définit le même style que le ‘blockquote’. C’est loin d’être satisfaisant comme solution mais dans l’immédiat je la trouve plus acceptable que toutes les solutions que j’ai pu voir par-ci par-là, car mon code reste conforme aux spécifications et donc est standard. De plus je garde le fonctionnement de wpautop, car il m’est bien utile. Je ne bidouille pas le code php, ni javascript où je n’ai surtout pas à mettre les mains. Pour finir effectivement je suis obligé de manipuler le HTML, mais cette solution m’oblige à le travailler dans le cas d’une citation uniquement.

Si, par hasard, un lecteur avait une solution plus élégante, je suis preneur !

Ecrits vaguement relatifs

• WordPress et les balises magiques
• Ding !
• Outils
• Pour que le nord ne soit pas jaloux du sud !
• Mes extensions WordPress