~bohwaz/blog/

Le problème majeur de la plupart des CMS, wikis, blogs, etc. c'est d'avoir chacun une syntaxe différente. Il y a bien des tentatives d'uniformiser tout ça, et je l'ai tenté plusieurs fois à travers notamment la classe FormatHTML qui formattait plusieurs syntaxes: BBCode, SPIP, <PRé>Textes Julika et Bérénice, wiki2xhtml, etc.. En théorie c'était très bien cela permettait de mixer toutes les syntaxes selon ses envies. Le problème étant que les syntaxes se recoupent. Par exemple un lien en Spip est [texte->lien], en wiki2xhtml c'est [texte|lien], etc.. Ce qui menait à des conflits complexes.

Plus tard il m'a semblé que wiki2xhtml était la syntaxe la plus pratique et la plus répandue (notamment à cause de DotClear), je l'ai donc utilisée dans WikiKubbe et L'encrier (moteur de journaux en ligne), mais après plus d'un an d'utilisation je m'aperçoit de plus en plus que cette syntaxe est totalement naze, avec des principes débiles qui vont à l'encontre de toute logique.

Après diverses réflexions je me suis dit que la meilleure solution c'est de faire directement du xHTML. Et oui, le xHTML c'est une très bonne syntaxe, très simple, sémantique, et mondialement connue. Le truc c'est que ce n'est pas très intuitif pour les débutants, et que son écriture est fastidieuse pour les utilisateurs expérimentés. A cela il existe donc deux solutions.

Pour les débutants : du WYSIWYG !

Pour les débutants, le WYSIWYG semble tout à fait indiqué, cependant il existe plusieurs problèmes majeurs à l'utilisation de WYSIWYG en Web. Le premier c'est la différence d'implémentation des modes d'édition entre les navigateurs. Là ou Opera et IE permettent d'éditer n'importe quel élément de la page via la propriété javascript contentEditable, Firefox et tout ce qui est basé sur Gecko exigent d'utiliser la propriété designMode uniquement sur un document entier, et donc d'utiliser un iframe. Première difficulté. Ensuite on ne peux pas simplement transformer un textarea en éditeur wysiwyg, sinon ça serait bien plus simple. Il faut donc utiliser un iframe obligatoirement, qu'il faudra synchroniser avec un textarea caché pour que le serveur reçoive le contenu.

Autre problème majeur, le markup généré par les navigateurs. En plus d'être souvent invalide et non sémantique, il est totalement hétérogène. Là ou IE fait des <em>, Firefox fait des <span style="font-style: italic;"> et Opera des <i>. Débile. On pourrait se dire qu'on a qu'à faire comme dans un textarea en jouant sur la sélection (comme le font MediaWiki et Dotclear 1.2 par exemple), et en rajoutant nos propres tags, sauf qu'il n'est pas possible de modifier la sélection en javascript sur un div, ça aurait été trop simple...

Heureusement des codeurs fous gentils développeurs se sont déjà penchés sur le problème, notamment The Man in Blue qui a fait un widgEditor tout à fait intéressant. Il formatte à peu près comme il faut, même s'il ne prends pas en compte les spécificités d'Opera, ce ne sont que quelques lignes à rajouter. On a donc un éditeur WYSIWYG qui fournis presque quelque chose d'intéressant. Pour le filtrage de tags en aval on utilisera un parseur de code qui fera les finitions, on va voir ça plus bas.

Pour les utilisateurs expérimentés : le xHTML assisté

Le principe du xHTML assisté c'est d'avoir un champ textarea dans lequel tous les tags xhtml sémantiques soient acceptés, sauf <p>. On peux taguer le texte avec des boutons utilisant javascript, comme sur MediaWiki ou DotClear 1.2, les tags qui ne sont pas autorisés sont transformés en entités HTML, ainsi que les tags précédés par \ (escaping de tags ;) ). Les tags de bloc de paragraphe et de retour à la ligne <br /> seront ajoutés automatiquement, ainsi il suffit de laisser une ligne vide pour faire un nouveau paragraphe et un retour à la ligne donnera... un retour à la ligne. Simple. Il n'y a rien d'extraordinaire, simplement une aide au formattage xHTML.

Tout cela est possible grâce à une class Garbage2xhtml qui est une sorte de tidy en PHP, mais sans les dépendances. Elle va simplement parser une chaîne de caractère et selon les options qu'on lui a donné (notamment les tags et attributés autorisés) il va corriger le code HTML. Ainsi les balises fermées mais non ouvertes, et ouvertes mais non fermées passeront à la benne. Les tags et attributs non autorisés également. Il va également transformer les tags b et i respectivement en strong et em notamment. Bref elle va tenter de faire quelque chose de valide et sémantique. Elle évite également pas mal de failles de XSS (même si c'est difficile de tout bloquer).

Voilà ce sont les pistes que j'ai exploré jusque là, et que vous retrouverez bientôt dans PitiCMS, un CMS censé être simple/léger/pratique, mais j'en reparlerais lors de sa sortie d'ici quelques jours. En attendant pour illustrer cet article un peu de code :

• class.garbage2xhtml.php qui nettoie le code HTML
• class.blockformat.php qui permet de gérer automatiquement les <p> dans un texte n'ayant que des retours de ligne.