La syntaxe wiki n'est plus ce qu'elle était
Par Laurentj le mercredi, juin 28 2006, 11:17 - Technologies Web - Lien permanent
La syntaxe wiki a été inventé pour une chose : mettre en forme un texte de façon trés simple et la plus naturelle possible, sans avoir à apprendre ce "complexe" langage qu'est le HTML. Trés pratique donc pour les internautes qui veulent publier sur le web (au hasard, via un wiki :-) ) et qui n'y connaissent pas grand chose en techno web. Et c'est une alternative trés crédible face aux editeurs wywiwyg en ligne qui génèrent du code HTML immonde le plus souvent. Moi même j'apprecie la syntaxe wiki, dans dotclear par exemple : cela m'évite d'avoir à taper des balises html dans tous les sens.
Cependant, la syntaxe wiki, volontairement simpliste (sinon elle perd de son interêt), peut être limitée dés que l'on veut faire une présentation un peu complexe. Cela m'arrive dans dotclear, et c'est pourquoi j'écris alors ces billets "complexes" en XHTML, et non en syntaxe wiki. C'est ce qui est sympa dans dotclear : on peut choisir la façon d'éditer son billet.
Par contre ce n'est pas le cas dans d'autres CMS. Mediawiki par exemple, celui qui motorise wikipédia. Les besoins d'éditions évoluant, les utilisateurs voulant faire des presentations plus complexes dans les pages, la syntaxe wiki utilisée dans ce CMS a évolué. Mais elle a tellement évolué qu'elle en est devenue selon moi trop complexe. Elle est maintenant à l'opposé du but premier de la syntaxe wiki ! Ce qui est un comble je trouve. (Remarque : c'est trés certainement le cas pour d'autres systèmes wiki).
Un exemple. Prenons au hasard cette page sur la coupe du monde de coureurs de baballes (Note : je déteste le foot, je déteste les supporters et encore plus tout ces beaufs qui klaxonnent et crient dans la rue à 11h du soir, et qui réveillent tous les bébés du quartier, y compris ma fille). J'ai pris cette page car elle a de jolis tableaux bien coloré et complexes à réaliser en wiki. Tenez, par exemple celui-ci :
Voilà ce que cela donne en wiki :
{|border="0" cellspacing="0" cellpadding="1"
|-
|colspan="10" style="background:#98A1B2;color:#FFFFFF"|'''Groupe A'''
|-bgcolor="#E4E4E4"
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|
!style="border-bottom:1px solid #AAAAAA" width="150" bgcolor="#F0F0F0"|'''Équipe'''
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|Pts
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|J
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|G
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|N
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|P
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|BP
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|BC
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|Diff
|-align="center" bgcolor="#CCFFCC"
|1||align="left"|'''{{GER football}}'''||9||3||3||0||0||8||2||+6
|-align="center" bgcolor="#CCFFCC"
|2||align="left"|'''{{ECU football}}'''||6||3||2||0||1||5||3||+2
|-align="center" bgcolor="#FFBEBE"
|3||align="left"|''{{POL football}}''||3||3||1||0||2||2||4||-2
|-align="center" bgcolor="#FFBEBE"
|4||align="left"|''{{CRC football}}''||0||3||0||0||3||3||9||-6
|}
|valign="top" style="border:1px solid #AAAAAA"|
{|border="0" cellspacing="0" cellpadding="1"
|-align="center" bgcolor="#F8F8FF"
|width="110"|Ven [[9 juin]] 18h
|width="150" align="left"|{{GER football}}
|width="20"|'''4'''
|width="20"|'''2'''
|width="150" align="left"|{{CRC football}}
|width="30"|(1{{e}})
|-align="center"
|Ven [[9 juin]] 21h
|align="left"|{{POL football}}
|'''0'''
|'''2'''
|align="left"|{{ECU football}}
|(2{{e}})
|-align="center" bgcolor="#F8F8FF"
Et ce n'est qu'un extrait du tableau... Vous avez remarqué tous ces signes cabalistiques de partout ? Digne des hiéroglyphes ! Même pour un habitué du wiki comme moi, c'est incompréhensible. J'imagine que pour des internautes non développeurs web, c'est tout aussi complexe. On est obligé de lire le looonng manuel de la syntaxe, en particulier celle spécifique aux tableaux (aide pas du tout évidente à trouver au passage..).
Je pense qu'il aurait été préférable de laisser la possibilité d'écrire du html pour les présentations complexes, comme le permettent certains autres systèmes wiki. Cela a selon moi plusieurs avantages :
- l'aspect verbeux du HTML permet à un débutant de mieux s'y retrouver. On imagine plus facilement ce que désigne le texte dans un <caption> dans un <table>, mais beaucoup moins celui qui suit ce hiéroglyphe
|+, l'équivalent wiki dans mediawiki. - apprendre les quelques balises html n'est pas inutile : cela peut reservir plus tard, pour d'autre chose, étant donné que c'est un standard, que c'est la base des pages web. Par contre, la syntaxe wiki de wikipédia, on ne la retrouve que... dans wikipédia (et les quelques autres sites qui utilisent mediawiki)
À la limite, le mieux est peut être même d'abondonner la syntaxe wiki, et de proposer un éditeur wysiwyg en ligne (genre fckeditor). Même si ils sont eux aussi souvent perfectibles..
Je reconnais toutefois que l'édition en ligne est une chose techniquement complexe. Et c'est tout de même dommage que cela n'ait pas beaucoup évolué depuis quelques années dans les navigateurs (surtout dans un certain navigateur avec un E bleu).
Commentaires
Oui enfin tu enfonces des portes ouvertes là hein. Vas voir la liste des conférences techniques de wikimania, la conférence qui se tient début aout à Cambridge et tu veras que c'est un problème majeur.
je ne savais pas l'édition de tableau aussi complexe, j'avais dans l'idée de créer une syntaxe wiki complette convertible en xhtml 1.1, mais je ne penser pas obtenir ce genre de nuage de code ...
enfin je n'ai pas encore fini ma reflexion, on vera ce que ca donne.
Désolé de pas être au courant de tout ce qui se passe sur le web hein ;-) Je ne connais en plus pas l'actualité des developpements de mediawiki wikipedia. J'ai fait simplement ce billet suite à une remarque que je me suis fait en tombant par hasard sur cette page de wikipedia et en regardant par curiosité comment ils faisaient ces tableaux colorés...
Mais bon, si tu dis que tous le monde est au courant..:-)
(j'aime bien les "va voir" sans liens... ;-) )
Déjà utilisé le reStructuredText ?
http://docutils.sourceforge.net/rst.html
J'avoue avoir un énorme plaisir à lire ces lignes. Il y a un peu plus d'un an et demi, ce débat était déjà venu sur ce blog via le BBCode. À l'époque je soutenais que le BBCode était plus intuitif que la synthaxe wiki, en particulier pour qui connaissait un peu de HTML. Bien sur, avec quelques exemples bien choisi, il était facile de prouver le contraire de mes thèses.
Mais la situation actuelle prouve bien que dès qu'on commence à faire des choses un peu complexe, aucune synthaxe ne peut être vraiment intuitive. Le HTML, le BBCode, le wiki, toutes ces synthaxes ont été créés au début dans un souci de simplicité. Mais l'humain étant ce qu'il était , il ajoute sans cesse des fonctions au détriment de la simplicité et de la standardisation. De ces trois synthaxes, seul le HTML possède de vraies specifications universelles, mais leur respect est loin d'etre un succès.
J'ai tout autant plaisir à lire cette conclusion, vu qu'elle est très proche de celle que j'avais à l'époque et que j'ai toujours :
On voit tout de même une nuance de taille : je ne crois absolument pas en la pertinence à long terme de bricolage de type fckeditor, même s'ils sont de qualité. Encore une fois, le web doit revenir à ses origines : un éditeur WYSIWYG intégré de base à tous les navigateurs, sortant du code valide si possible, est à mon sens un des plus grands défis du web actuel : ardu mais indispensable.
Laurent tu as tout à fait raison de pointer ça du doigt mais l'alternative que tu propose (édition en (X)HTML directe) est tout aussi délicate à mettre en oeuvre. En effet, tu omet de parler d'un autre avantage important de la syntaxe wiki (en dehors de sa simplicité initiale) : la possibilité de pouvoir nettoyer aisément (via un script PHP relativement simple) le code saisi pour éviter ainsi tout problème de XSS (cross site scripting). Autoriser la saisie directe de code (X)HTML directement dans un wiki serait la porte ouverte à toutes les fenêtres si je puis dire tant il est ensuite difficile de nettoyer correctement le code saisi (preuve en est les exemples de XSS cités dans cet article : http://www.alistapart.com/articles/secureyourcode). Bref le sujet n'est vraiment pas simple ...
SToto98 : je ne suis pas du tout de ton avis..
Etant l'auteur d'un moteur de convertion wiki -> xhtml, je peux t'assurer que nettoyer du code wiki est loin d'être facile. Alors que pour du XHTML, tu as des outils tout prêt :
Bref, c'est un faux argument. Si il y a tant de problème de sécurité dans les trucs qui autorisent le html, c'est parce que les devs ne prennent pas le temps de faire un truc qui vérifiait bien la saisie. Et du manque aussi d'api DOM ou autre par exemple dans php 4 et précedent. Ce n'est plus le cas en PHP5. Des trous de sécurité XSS, tu en a aussi dans les moteurs wiki..
Bref, la syntaxe utilisée n'a rien à voir avec la sécurité.. Ce sont les moteurs de transformation ou de lecture des textes saisies qui sont troués.
un wysiwyg integrer a la manière d'un élément de formulaire, c'est assez séduisant.
<texteditor style='sidebar: top;'> <p>voici un paragraphe</p> </texteditor>
je me demande a qu'elle point ceci est réalisable avec les outils de Mozilla ??
je m'en vais poser la question ^^
eu ça existe déjà.. Tu crois que FckEditor &cie se basent sur quoi ? ;-). En gros, ce genre de script javascript ne font que rajouter une barre de bouton... Pour certains, ils nettoient également un peu le code... Rechercher "midas" pour l'editeur de mozilla..
halte a la polution ^^ suite ici -> http://xulfr.org/forums/read.php?7,5294
sympthique comme news cç m'inspire ^^
A quand un éditeur wysiwig en ligne qui génère correctement du code XHTML ?
j'ai envie de te dire ... créer le !
Et le pire c'est quand on se retrouve à utiliser plusieurs outils différents qui ont tous une syntaxe Wiki différentes. Il est surprenant comment la communauté des logiciels libres qui est si prompte à vouloir défendre les standars est incapable de mettre ce genre de chose en place.
lordphoenix : tout à fait d'accord. Y a eu une tentative (le lien en question n'est pas accessible, mais j'en parlais il y a presque 3 ans).. mais finalement il n'en est rien ressorti.. Le problème c'est qu'il y a trop une histoire de goût personnel et d'habitude dans la façon d'écrire, de se representer les élements d'un texte... Et il faudrait un groupe fédérateur.
-> ça serait mieux que cela soit un attribut CSS pointant éventuellement sur une définitions des règles d'écritures :
Non ? Qu'est-ce que vous en pensez ?
Exemple :
HTML :
<div id="commentaires"> <h3>Vos commentaires</h3> <dl> <dt><strong>Dupont</strong> Le Lundi 32 Février 3007 à 25:72</dt> <dd>Super commentaire !</dd> </dl> <h3>Ajouter un commentaire</h3> <form action="/save"> <p><label for="c_nom">Nom</label> <input id="c_nom" type="text" /></p> <p><label for="c_content">Commentaire</label> <textarea id="c_content"></textarea></p> </form> </div>-> Et oui, il faut penser à garder un formulaire pour poster les nouvelles données.
CSS :
#commentaires textarea { editable-rule: url(section-news.xml); }Bon, ce n'est peut-être pas la meilleur idée ...
Un Working Group au W3C ? :-) (Bon, OK, faudra pas être pressé ;-))
J'oubliais ... Un point fort pour le langage Wiki par rapport à du HTML (avec editeur wywiwyg ou pas) C'est la possibilité de pouvoir faire des comparaisons entre les différentes versions d'un article et ça, très facilements.
Exemple : http://fr.wikipedia.org/w/index.php?title=Feuilles_de_style_en_cascade&diff=8228909&oldid=8193121
Il y a (eu) des projets anglo-saxons de standardisation mais ils semblent à l'abandon
IETF RFC Draft for standardisation of the Wiki Syntax
WikiMarkupStandardWorkingGroup
Le sujet reste d'actualité, il fait partie du Symposium 2006 sur les Wikis qui aura lieu cet été au Danemark
jycronier : te fatigue pas à chercher. Tout ceci existe comme je le disais.
jycronier : au fait, les outils qui permettent de signaler les différence entre deux documents xml/xhtml, ça existe aussi hein ;-)
LaurentJ : 2 - jycronier : 0
Bien vu ! :-) Je n'ai pas assez réfléchis.
Laurent, si tu savais comme je plussoie
Oui, la syntaxe wiki est pratique pour les choses "simples", comme mettre en italique, en gras, ajouter un hyperlien, ...
Pour les structures complexes (tableaux surtout), il vaut mieux intégrer du html généré en javascript avec le DOM. La structure de départ du tableau serait défini avec une série de boîte de sélection (un peu comme dans openoffice par exemple).
L'intérêt principal du wiki ce n'est pas que c'est simple, mais c'est que le rendu au final se rapproche du rendu du texte, ce qui rend le texte bien plus facile à éditer en mode texte.
Laurent, tu m'autoriseras un léger bémol à l'optimisme concernant le Design Mode dans Gecko. Faire un éditeur WYSIWYG, même simple, ne consiste pas à juste ajouter une barre d'outils. C'est aussi, créer un iframe, y mettre un document et le passer en design mode. Rien qu'avec Gecko, ces trois étapes sont compliquées et loin d'être limpides pour qui cherche à faire quelque chose de propre. Je ne parle même pas de l'aspect cross browser, où IE et Opera s'en sortent presque mieux que Gecko. Bref, les TinyMCE et autres FCK sont des horreurs mais doivent aussi composer avec des contraintes délirantes. Et je n'ai même pas parlé des éléments sélectionnés ;-)
Wiki ou WYSIWYG ?
La solution c'est une combinaison des deux!
La recette: Vous mettez un peu de Wiki très light ajoutez un editeur WYSIWYG pour la création du document Xhtml1.x, CSS et pour terminer une touche (click) pour la création du RSS en guise dessert!
La recette est réussie si votre menu:
Le dernier plat réalisé: http://www.chateaudevilla.ch
Santé et bon appetit!
PS: Le titre de la recette 1Work. :-)
NB: N'essayez pas d'analyser le code de la recette!
Vous courrez un grave danger et risquez un mal de crâne (taux d'alcool très élevé. :-)
On vit exactement le même problème dans claroline.
Succès dû à la simplicité et la première réaction de tout codeur qui commence à y travailler est d'ajouter, ajouter, ajouter, complexifier....
La règle de base est pourtant simple pour bonne une syntaxe
mis à par les liens, un source wiki doit avoir l'apparence d'un texte "sans tag".
Imprimé on doit pas savoir que c'est un source.
Pour tempérer ta remarque Laurent, il est possible (sauf erreur) dans Mediawiki d'insérer des morceaux en HTML. Donc typiquement, il doit être possible de composer les tableaux complexes en HTML si la syntaxe wiki est trop lourde.
De façon plus générale, je pense que le problème fondamental des tableaux, c'est que ce sont des structures intrinsèquement 2D, alors que le texte est intrinsèquement 1D. Il me semble donc que tôt ou tard, un markup textuel pour composer des tableaux (que ce soit du HTML, du wiki ou du LaTeX) finit par être indigeste lorsque les tableaux deviennent complexes. De mon point de vue, les seuls éditeurs de tableaux qui ne finissent pas par devenir confus sont les éditeurs visuels (comme celui de Word ou de Nvu il me semble), car, justement, ils travaillent en 2D.
ChrisJ: oui, c'est effectivement le cas: le code HTML inséré dans une page de Wikipedia est rendu tel quel. Voir par exemple les deux pages suivantes:
http://en.wikipedia.org/wiki/List_of_members_of_the_Swiss_Federal_Council http://fr.wikipedia.org/wiki/Liste_des_conseillers_fédéraux_de_Suisse#Chronologique_global
La table, assez compliquée, est globalement la même en français et en anglais, mais la française est écrite en code Wiki, et l'anglaise en HTML.
Point positif, ça permet de laisser le choix à l'utilisateur. Point négatif, il est plus difficile de parser la page s'il faut connaître le langage du Wiki, plus le HTML, etc, etc.
Frédéric
J'ai switche de BBedit a Mate recemment qui est un editeur interessant et un peu plus geek en termes de configuration. Notamment une feature tres interessante, c'est que l'on peut faire un hook de l'editeur Apple Mail pour qu'il utilise Mate. Je me demande si il serait difficile que cela d'avoir une option dans les navigateurs qui diraient. Edition de formulaires, choisir application... Ainsi on pourrait aller choisir l'editeur de son choix en wysiwyg ou code source. (reste a gerer bien sur les formats, mais ce serait un progres a mon avis).
Karl, je crois qu'il y a une extension pour Firefox qui fait justement ça :)
Ah voilà http://mozex.mozdev.org/ mais ça a l'air tout pas maintenu :)
Je développe un système pour inserrer des objets html dans un article en syntaxe wiki. Pour simplifier, imaginez une gestionnaire d'image comme dans dotclear qui permet d'inserer une image dans le billet grace à une petite syntaxe wiki. Ce serai pareil mais à la place d'une galerie d'image se serai une galerie de codes html. Ça peut servir pour inserrer un tableaux complexe en xhtml ou un script. Et on peu inserrer le meme "objet" dans plusieurs articles sans avoir à corriger tous les articles quand on met à jour le tableau par exemple.