mise à jour 03/10/2003 : j'ai modifié un petit peu la syntaxe wiki que je propose suite à certains commentaires que j'ai pu lire ici ou ailleurs.


Le problème éternel pour les applications web : permettre à l'internaute de pouvoir saisir du texte tout en lui permettant de le formater à sa convenance et de produire un code HTML valide. J'y suis confronté régulièrement lors de la réalisation d'application intranet.

Il y a bien des solutions wysiwyg (en javascript), mais elles ne sont pas satisfaisantes : soit elles sont incompatibles avec tout les navigateurs (car utilisant très souvent des instructions javascript propriétaires), soit elles produisent du code HTML invalide avec la norme utilisée sur le site (genre, mon site est en HTML strict, et ce composant me génère des balises FONT etc...), soit elles ne permettent pas un formatage évolué (impossible de générer des listes de définitions par exemple).

On pourrait permettre à l'internaute de saisir directement du HTML, mais encore faut il :

  • qu'il connaisse le HTML
  • qu'il produise du HTML compatible avec la norme utilisée sur le site

A cela faut ajouter tout les risques de sécurité comme le Cross Site Scripting etc...

D'autres outils comme phpBB, proposent un balisage similaire au HTML, légèrement simplifié. Mais cela reste tout de même lourd, embêtant à écrire, et compliqué pour l'internaute lambda.

Bref, on est encore loin de l'eldorado.

En attendant de trouver mieux, les wikis ont très certainement apportés la réponse à cette problématique. Ils proposent un balisage très simplifié, pour mettre en forme du texte. Exemple : pour faire une emphase, on entoure l'expression par deux caractères souligné de chaque coté. Le moteur wiki transformera cela en balises HTML strong. Pour faire une liste HTML UL rien de plus simple : on débute chaque ligne par une étoile.

Cette syntaxe apporte de nombreux avantages :

  • La syntaxe wiki est très simple et relativement intuitive. En tout cas, beaucoup plus que le HTML. L'utilisateur lambda n'a pas à apprendre du html pour formater un texte qu'il saisie dans un formulaire d'une page web.
  • l'application garde le contrôle du code HTML : pas de risque de balises HTML mal formée lors de la saisie. De plus, le code html généré pour l'affichage peut respecter la norme choisie par le webmestre. Si un jour il passe du HTML au XHTML, il y a juste le petit moteur wiki à re-paramétrer pour que les dizaines de textes saisis en wiki, stockés en base de donnée par exemple, soient affichés dans la nouvelle norme.
  • pas besoin de surcouche javascript wysiwyg sur les zones de saisies, pour cacher le code généré ( scripts qui pour la plupart sont incompatibles entre navigateur, même si les choses s'améliorent). C'est compatible tout navigateurs

Bref, on s'aperçoit que la syntaxe wiki répond de façon assez élégante à ces problèmes de formatage.

Mais la syntaxe wiki est victime de son succès à cause d'une non standardisation : chaque wikis, chaque outils qui utilisent une syntaxe wiki ont leurs propres syntaxes. Ce qui fait autant de syntaxes wiki à apprendre pour l'internaute quand il se balade d'un site à un autre.

A l'image du W3C, des internautes tentent donc d'établir une norme... pour la syntaxe wiki ! Et ça se passe dans le crao wiki. Je trouve ce travail interressant à plus d'un titre.

D'une part, on peut s'apercevoir des conséquences de la non existence d'une norme : le draft de la syntaxe universelle wiki nous montre tout les types de syntaxe wiki existante. C'est affolant. L'interopérabilité en prend un coup.

D'autre part, le travail réalisé sur cette syntaxe universelle, nous permet de prendre conscience de la difficulté de la mise en place d'une norme, de la nécessité de faire des concessions etc.. (Message subliminal destiné à toutes ces personnes qui critiquent le travail du W3C...).

Bref, pas facile de faire une norme de syntaxe wiki qui soit à la fois ultra simple à utiliser, hyper intuitive, et suffisamment riche et efficace pour qu'elles puissent être utilisée par tout le monde, du newbie de chez newbie au pro du HTML.

Parmis les syntaxes utilisées par les nombreux outils, référencées dans le crao wiki, je choisirais celles-ci.

Les paragraphes (p)

Une ligne vide au moins (donc 2 retours à la ligne au minimum), indique un nouveau paragraphe. Dans l'imprimé, il y a toujours un espace entre les paragraphes. Il faut donc au moins une ligne vide pour générer une balise P.

mise à jour : du texte à la suite d'un titre, d'une liste etc, débute forcément un paragraphe.

Le retour à la ligne forcée (br)

mise à jour : Au départ, je trouvais inutile l'utilisation d'une balise spécifique. Mais finalement, j'ai changé d'avis, suite aux commentaires : ça pose des problèmes quand on fait par exemple du copier coller d'un texte dans lequel il y a un saut de ligne à la fin de chaque ligne, comme les mails. Donc il ne faut pas interpréter systématiquement les sauts de lignes en les remplaçant par un BR. Proposer une balise (les 3 signes pourcents semble être un consensus) qui permette d'indiquer un retour à la ligne quand on en a besoin (pour une adresse, un poème...).

simple emphase (em)

Je suis pour le double apostrophe. Quand on fait une emphase, à l'écriture, on l'encadre bien souvent de quotes ou doubles quotes..

forte emphase (strong)

Pour cette sémantique, bien que l'utilisation du double souligné soit très utilisé, je ne suis pas pour à 100%. Déjà, comme son nom l'indique, on pourrait penser que le caractère souligné, ce soit pour souligner, pas pour spécifier une emphase (quoique, pour spécifier une emphase, on pourrait souligner les termes). Je proposerais plutôt les doublements de doubles quotes : ""forte emphase"", ' 'simple emphase' '

mise à jour : il est possible de confondre le " et le doublement de '. Donc il faut choisir un autre caractère. L'étoile est couramment utilisé...

Titres (h1...)

Des points d'exclamations en début de ligne sont adaptés je pense. Le point d'exclamation montre bien une importance. Et un titre, c'est important. Après, le débat ce situe sur : ordre croissant ou ordre décroissant ? Autrement dit, trois point d'exclamation désigne t-il un titre hiérarchiquement plus important ou moins important par rapport à 1 point d'exclamation ? Je serais tenté de rester logique : 3 points d'exclamation désigne un titre plus important qu'un seul.

Liste non ordonnée (ul)

La majorité des wikis proposent une étoile (astérisque) en début de ligne pour indiquer chaque élément de la liste. Pourquoi pas. Personnellement, quand j'écris sur un papier, j'ai plutôt tendance à utiliser des tirets. Mais certains pourraient avoir l'habitude des étoiles. Je serais plutôt favorable à l'utilisation possible des 2 : étoile ou tiret.

Liste ordonnée (ol)

Le dièse habituel reste la solution idéale. Par contre, les propositions d'utiliser des numéros : pas du tout. On ne devrait pas à les spécifier : c'est pénible à écrire. Et si on change l'ordre des éléments, il faut tout re-numéroter ! Et puis, cela ne se traduirait alors pas par un ol, mais un ul. On a donc un problème de sémantique coté HTML. Gardons le dièse.

Liste de définition (dl)

Là, c'est un truc sur lequel il faut réfléchir. Le point virgule / deux points proposé dans phpWiki est-elle suffisante ?

autres

Il y a un certain consensus entre tout les wikis, et je n'ai pas grand chose à redire. Donc :

  • texte préformaté (pre) : je pense que l'espace en début de ligne est tout à fait adapté.
  • Bloc de citation (blockquote) : Signe supérieur en début de ligne
  • Tableau : ligne commençant par le caractère |, et chaque élément de colonne séparé par ce même caractère.
  • Liens : y a pas photo, la syntaxe proposée dans wiki2xhtml est suffisamment riche et simple. On pourrait ajouté également la reconnaissance automatique dans le texte des liens commençant par http://.
  • Images : idem que les liens.
  • Séparateur (hr) : 4 tirets sur une seul ligne.


Il en reste plein à rajouter également, de façon à coller au plus prés de HTML. Il manque des balises wiki pour représenter bon nombre de balise inline par exemple :

  • acronyme (acronym) : je propose la syntaxe wiki2xhtml
  • abreviation (abbr) : ?
  • citation (q) : je propose la syntaxe wiki2xhtml
  • code (code) : je propose la syntaxe wiki2xhtml
  • ins, del : ?
  • samp, var : ?

Il me reste donc à participer et à compléter le crao wiki :-)