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.
12 réponses à “Garder un code valide, un combat de tous les instants”
Oups, je suis repéré :op
J’ai effectivement passé l’AJBlog au validateur W3C pour vérifier si la synthèse wiki avait des conséquences sur la validité de ton blog car je suis confronté au même problème: sur le site que j’ai créé, j’ai dû rajouté des fonctions à la barre d’outils servant à rédiger billets et dossiers. Or l’utilisation de ces nouvelles fonctions donne un code invalide: couleurs, taille de police…
J’ai passé la page d’accueil et la page de commentaire du billet précédent.
Apparement Dotclear possède un plugin wiki2xhtml pour convertir la syntaxe wiki en xhtml.{{
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.}}
Tout à fait d’accord avec toi. D’autant plus que le site que j’ai réalisé est multi ultisateurs/rédacteurs… Je pense qu’il faudrait séparer encore contenu et contenant lorsque l’on rédige un billet/dossier en proposant un mini éditeur de css simplifié pour faire la mise en page.
Juste une remarque en passant: vous avez remarqué que pour un journal papier, il y a un maquettiste, mais aussi un secrétaire de rédaction qui corrige les textes et les fait rentrer dans la maquette (place alouée, choix de sous-titres, etc.)?
De même, lorsqu’on réalise un document pour le print, le client n’est pas en charge de faire la mise en forme du texte, en l’intégrant directement dans un gabarit. Il fournit le contenu, et le graphiste/maquettiste met ça en forme.
Si on veut atteindre un niveau de qualité équivalent (en termes de professionnalisme, pas de finition graphique ou autres détails peu significatifs), il nous faut donc:
Dans le cas de ta cliente qui gère un groupe de rédacteurs, Aymeric, Word n’est pas un outil adapté. Tout simplement. Attention, je ne dis pas qu’il y aurait un outil plus adapté, peu couteux et facile à mettre en place. En termes de cout, faire un investissement en acquérant des licences, déployant un logiciel, formant les rédacteurs… sera peut-être exclu, et il vaudra mieux dépenser de l’argent – mais moins – en temps perdu à reprendre les textes.
Dans le cas d’un CMS géré par une ou deux personnes (site de PME par exemple), et si la gestion des contenus se fait en interne plutôt que par un prestataire web, il faudra mettre le client en face du choix suivant :
C’est au client de faire le choix. Pour ma part, je recommanderai bien sûr très chaudement le deuxième.
Au passage, certains éditeurs permettent à l’utilisateur d’attribuer à des éléments (span créés à la volée ou paragraphe en cours) des styles prédéfinis par l’intégrateur. Ça peut être intéressant pour donner un peu de «souplesse contrôlée».
Sinon, je suis également fan de la syntaxe wiki de Dotclear. Ça a l’air moins évident et ça demande une information un peu plus appuyée du rédacteur, mais les gains (en temps économisé par la suite) me semblent non négligeables.
Dans le même style, on a Textile (Textpattern) et Markdown. J’aime bien Markdown, qui s’inspire de la «mise en forme» courante en texte brut (mais très anglo-saxone).
Jérome : pour moi, la rédaction en mode Wiki utilisée par Dotclear, est le meilleur outil de rédaction pour garder un code valide.
Certes, ce n’est pas très sexy, on ne peut pas faire joujou avec la mise en page du texte d’un billet, mais sincèrement, il y a tout ce qui est utile pour faire de la rédaction « valide ». Donner plus de liberté à un utilisateur, c’est le « tenter » et il finira toujours par bidouiller et donc pourrir le code.
Salut,
En effet il est très difficile de garder un site valide, surtout quand beaucoup de personnes interagissent dessus (intégrateur, codeur, client, …).
Sinon il existe Always Valid ( http://alwaysvalid.com ) qui vérifie pour vous la validité de vos pages et vous préviens en cas d’erreur. Evidement dans la plupart des cas on se limitera à la page d’accueil mais c’est déjà un début.
à Ayméric
Ah mais je suis d’accord avec toi! Maintenant si tu me dis que la syntaxe wiki permet de garder un site au normes, alors vas pour cette solution.
D’ailleurs je crois que la barre d’outils de mon CMS au départ proposait des fonctions qui ne cassaient pas la validité du code. Malheureusement on m’a demandé de rajouter les fonctions qui manquaient par rapport à Word car il y a un besoin de mettre en forme (couleurs,etc). De plus, je crois que la syntaxe wiki ne permette pas de changer la couleur du texte ou de jouer sur la taille du texte.
Mes utilisateurs ont besoin d’une joli mise en page du texte. Je suppose que ça aide à faire passer l’information.
@Country: Le problème avec de tels validateurs c’est qu’il te montre les erreurs mais pas comment les corriger, en plus c’est en anglais. Et pour corriger, faut également penser aux rédacteurs…
@Jérôme : Ce genre d’outils s’adresse aux développeurs, qui savent généralement comment corriger ces erreurs (et comprennent l’anglais ;) ). Les rédacteurs se fichent des erreurs, tant que leur article s’affiche correctement sous IE, c’est le principal.
De plus, en théorie (je dis bien en théorie car en pratique c’est rarement le cas), si le site est bien conçu, un rédacteur ne peux pas rentrer de code invalide qui risque de « casser » le site.
Jérôme : c’est un des gros problèmes actuels, gérer la volonté des utilisateurs finaux en terme d’outils de rédaction.
Personnellement quand je suis confronté à ce genre de problèmes, j’essaie de faire jouer la carte de l’uniformité de la mise en page, car plus on laisse de liberté à l’utilisateur, plus le résultat final ne ressemble à rien : choix de couleurs catastrophiques, textes trop gros, abus de mises en forme inutiles…
Une de mes clientes gère un groupe de rédacteurs, quand ils ont des articles à rédiger, ils ont une matrice de fichier Word, avec une feuille de style aux petits ognons et des directives claires pour s’en servir. Au final, chacun n’en fait qu’à sa tête et c’est un réel cauchemar pour tout uniformiser par la suite.
Florent : je suis en train de travailler sur un outil avec des champs de rédaction « limitables » par l’administrateur en nombre de caractères et utilisant bien sur une syntaxe simple de mise en forme (même limitations que DC avec ajout des niveaux de titres et proposition en auto de titre de liens et de texte alternatif d’images).
Développement assez simple et forte valeur ajoutée en gain de temps de post production. Il faut juste que je trouve le temps de faire avancer le projet.
Bonjour,
Je pense que, dans l’urgence et le feu de l’action, nous sommes probablement nombreux à oublier cette vérification… un rappel bien utile donc ! Un rappel à l’ordre valable pour moi ;)
Si je m’efforce à la rigueur absolue pour le site pro, je m’accorde un peu plus de liberté sur mon blog pour l’ajout de services externes. Parfois je peux corriger mais pas toujours, ainsi la redoutable esperluette joue les trouble-fête dans les recommandations des Influenceurs.
Je recommande la lecture d’un article d’Elie Sloïm sur OpenWeb : Conformité, validation et surqualité (article très détaillé mais aussi très réaliste)
Amicalement,
Monique
@ Country: Bien que je sois un amateur, j’essaye de faire du boulot et j’arrive quelque fois à décrypter le compte-rendu du validateur et à corriger certaines erreurs. ;o)
Oui et c’est bien ça le problème. IE est un véritable casse-tête pour les css…
Ayméric : j’ai le même problème que toi et ta cliente. Sauf que dans mon cas, je ne peux pas parler de css car mes utilisateurs n’ont aucunes connaissances en html et css (sauf un) et donc je ne pas parler de feuille de style. J’ai bien une option qui permet de coller un texte fait sous Word et de nettoyer les balises mais bon…
Lorsque tu parles de matrice de fichier Word, c’est ce que je viens de décrire?
Sinon Florent a bien résumé le problème des CMS et confirme le besoin d’un rédacteur du Web.
Désolé si je n’ai pas lu les derniers commentaires (j’en ai lu les 2/3), mais je voulais réagir :p
En fait, ça me rappelle un commentaire que j’ai fait sur ton billet concernant les « pseudo-pros », où je t’expliquais que pour moi, utiliser des modules « tout fait » me posait problème, car je voulais maitriser chaque parcelle de mon code.
Tu en arrives à voir pourquoi de mon coté, je code le maximum de chose moi même (la seule chose que je n’ai pas encore fait, c’est un éditeur en javascript). Car en utilisant des modules, on a souvent des problèmes : validité du code (quelque fois les développeurs de certains modules n’y sont pas très regardants), encodage, bugs (c’est très génant lorsqu’un client relève un bug, et que tu dois lui expliquer que ce n’est pas toi qui a codé le module, et que tu risques de mettre un moment pour dénicher le soucis)…
D’un autre coté, tout coder soi même a aussi des défauts : tu n’est pas forcément sans faille, et donc tu peux laisser des failles de sécurité que la communauté aurait depuis longtemps remarqué et résolu; Ca te demande du temps (même si une fois fait, tu peux réutiliser ton code facilement)! Tu risque de faire quelque chose de moins complet que ce qui existe (mais peut être aussi plus léger, et plus rapide ;) ), …
Bref j’ai l’impression qu’à ton niveau, le soucis vient de la programmation. C’est logique, si ce n’est pas ta spécialité ;) Tout comme à mon niveau, c’est le graphisme :p
Je ne dis pas tout cela pour faire un rabat-joie, mais pour illustrer mon opinion ;) Cela dit, c’est très sérieux de ta part de se soucier de ces problèmes, alors que cela concerne la partie « programmation », ce qui est tout à ton honneur ;)
Bonjour Monique,
L’article est en effet très interessant, et il me rassure un peu car normalement le site que je fais avec un cms pour une association de personnes handicapées devrait montrer l’exemple en étant valide w3c. Cependant il n’en est pas moins accessible, et le principal objectif était que les adhérents puissent gérer le site. Et comme il est dit dans l’article mes ressources étaient limitées, et je dépendais du facteur temps et du facteur humain (collaboration entre différents responsables)…
En tout cas ça pose encore une fois la question suivantes: Quel contenu doit être accessible?
Même si on est d’accord pour dire qu’un site ayant un code non valide peut être néanmoins accessible.