À l’heure où l’usage d’outils de gestion de contenu (CMS) se généralise, on constate des dérives dans les solutions d’édition proposées aux contributeurs. En effet, les responsables de projets Web ont bien compris l’intérêt de séparer contenus et présentations grâce aux outils CMS. Néanmoins, par crainte d’un changement culturel trop fort pour les contributeurs habitués à l’usage de traitements de texte classiques, ils refusent souvent de pousser le concept jusqu’au bout. Cette peur du rejet entraîne l’aberrante utilisation d’éditeurs de texte riche produisant du HTML dans le corps de texte :
Or, ce choix va à l’exact opposé du but recherché (à savoir séparation du contenu et de la présentation). On permet aux contributeurs de reproduire toutes ses mauvaises habitudes :
– Mise en valeur des zones de texte sans règle : certains choisiront l’italique, d’autres le gras ou pire le bleu souligné (provoquant une confusion avec la signalétique standard d’une URL non parcourue) …
– Création de tableaux avec des mises en forme très personnelles (voir l’exemple des 2 tableaux ci-dessus)
– Utilisation de liens vers des contenus du site via URL (avec le risque que le contenu soit déplacé et le lien plus valable)
– …
Afin d’éviter de tomber dans ces travers, l’utilisation de raccourcis typographiques se généralise. Ces raccourcis permettent au contributeur de mettre en valeur des zones de son texte sans « embarquer » la présentation. Exemple d’utilisation de raccourcis typographiques:
Ce contenu est mis en forme de manière homogène en Front Office:
Actuellement, cette bonne pratique tend à se généraliser et se trouve mise en œuvre aussi bien dans des solutions de gestion de contenus, des wikis que des blogs avec des codes raccourcis qui ne sont malheureusement pas standardisés. Exemple de la gestion d’un lien pour avoir Google:
Dans SPIP :Google
Dans Dotclear :
[Google|http://www.google.fr]
Dans certains wiki :
[Google http://www.google.fr]
[[Google http://www.google.fr]]
[[http://www.google.fr Google]]etc…
Outre l’absence de standardisaton des raccourcis, le principal inconvénient reste que le contributeur doit attendre de voir la prévisualisation pour se rendre compte du rendu de son texte. Pour finir de convaincre les contributeurs les plus réticents du bien-fondé de cette approche, il faudra se tourner vers des éditeurs WYSIWYG générant du code « raccourcis typographiques » et ne permettant qu’un nombre restreint de possibilités. Certains éditeurs WYSIWYG « configurables » Open Source (FCK Editor, TinyMCE …) commencent à émerger mais leur intégration laisse encore à désirer. En effet, ces derniers produisent du XML ou du XHTML éloigné de la syntaxe raccourci typographique humainement compréhensible et le passage du WYSIWYG à la syntaxe produite peut être douloureuse. A noter en revanche que des offres commerciales Wiki telles que Confluence, JotSpot fournissent de telles solutions.
A moins de s’équiper avec de telles solutions, il faudra que les responsables de projets Web continuent à user de persuasion pour expliquer qu’ungras(pas si simple à écrire d’ailleurs dans mon gestionnaire de contenu 😉 ) est préférable à un gras.
