Garder un code valide, un combat de tous les instants

En vérifiant les statistiques de fréquentation du blog ce matin (oui, je sais, nombril tout ça…), je me rends compte qu’un visiteur a passé une de mes pages au « validateur » HTML du W3C.

Je me dis, tiens, ça fait effectivement longtemps que je n’ai pas passé mon blog à la moulinette et je m’empresse de vérifier tout ça… erreur… des tonnes d’erreurs en fait.

Et la faute est mienne, totalement, j’ai baissé la garde, je n’ai pas vérifié le code des nombreux « trucs » orientés promo que j’ai inséré ces derniers temps. Je pourrais dire, c’est leur faute, ils n’ont qu’à me donner des codes valides, mais au final, qui fait le choix d’icnlure telle ou telle chose, de coller tel ou tel code, si ce n’est moi.

Certaines erreurs étaient évitables (des codes en HTML4 alors que le blog est en xhtml), d’autres plus difficiles à détecter (attention ce qui suit n’intéressera que des « puristes »):

L’AJblog utilise un jeu de caractères UTF-8. Pour des raisons que je ne développerai pas ici (allez plutôt voir du côté d’Openweb lire cet article : Introduction aux jeux de caractères), tous les fichiers constituant la partie visible et lisible du blog sont encodés sans BOM (Byte Order Mark). Je parle bien ici des fichiers (PHP ou HTML), encodés, « en dur ».

Sauf que souvent, on utilise dans son blog ou dans son CMS des ajouts, des plugins, qui eux ne sont pas forcément encodés de la même manière. Bilan, votre jolie page que vous avez peaufiné aux petits ognons devient invalide suite à un conflit d’encodage de fichiers.

Ce que je veux souligner, c’est qu’il est actuellement extrêmement difficile de garder un site avec un code valide si on ne se créé pas des mécanismes de contrôle à la hauteur de ses besoins. Et encore, il s’agit de mon site, sur lequel j’ai entièrement la main, imaginez un projet avec différents intervenants techniques et de nombreux rédacteurs.

L’enfer est dans les détails.

Cordialement,
Aymeric Jacquet

Tags : ,