Je pense que depuis que les hommes peuvent taper du texte sur des ordinateurs, ils ont cherché la manière la plus simple pour mettre ce texte en page, lui appliquer du style et lui donner du sens. De manière générale, cela a conduit à deux grandes approches : celles qui reposent sur des éditeurs de texte qui affichent le résultat final en cours d’édition (les éditeurs WYSIWYG) et celles qui reposent sur les langages de balisage léger.
Je vais m’intéresser à ce deuxième groupe. Pas la peine que je vous fasse un cours. De nos jours, tout le monde a utilisé au moins une fois dans sa vie la syntaxe BBCode (sur n’importe quel forum PHPBB, par exemple) ou une syntaxe de style MediaWiki (sur Wikipedia ou un autre système de wiki).
Avec le temps, on a vu arriver un très grand nombre de langages de ce type. En plus des deux sus-nommés, j’ai en tête ReStructuredText (utilisé dans la documentation Python), AsciiDoc, Textile (utilisé dans les outils de 37signals, par exemple), Markdown (utilisé notoirement par GitHub et StackOverflow), POD (documentation Perl), ou encore Creole.
Je ne compte pas des formats comme Groff, Texinfo, LaTeX ou SGML comme des langages de balisages légers. Il suffit d’essayer une fois de faire un vrai document avec l’un de ces systèmes pour se rendre compte qu’il existe plus simple et moderne (mais moins performant − LaTeX est un vrai système de composition de page, particulièrement complet).
Je vais maintenant m’intéresser à deux de ces syntaxes : Markdown et Creole.
Markdown est rapidement devenu le langage de balisage léger le plus hype sur le web. Je n’ai pas vraiment compris pourquoi. Qu’on ne me dise pas que c’est grâce à ses qualités intrinsèques, chacun des langages existant possède des avantages et des inconvénients. Qu’on ne me dise pas que c’est grâce à sa documentation, qui n’est sincèrement pas terrible.
À côté de ça, la genèse de Creole est assez intéressante. Lors du symposium international des wikis en 2006 − et dans le cadre du Wiki Markup Standard Workshop − les créateurs des principales plate-formes de wiki se sont mis autour d’une table pour essayer d’accorder leurs violons au travers d’une syntaxe commune.
Personnellement, j’apprécie beaucoup la syntaxe de Creole. Elle emprunte un très grand nombre d’éléments communs à la plupart des autres langages équivalents. Et pour le reste, elle fait usage de double-symboles qui évitent toute ambiguïté.
Pour illustrer tout ça, je vais comparer les syntaxes de Markdown et de Creole.
Titres
Markdown utilise une syntaxe à base de dièse :
# Titre de premier niveau ## Titre de deuxième niveau
Creole utilise une syntaxe à base de égale :
= Titre de premier niveau == Titre de deuxième niveau
L’un comme l’autre peuvent être « équilibrés » :
## Sous-titre Markdown ## == Sous-titre Creole ==
Là où je pense que Markdown a fait la différence, c’est en proposant une syntaxe alternative qui correspond à ce qu’on a tous tendance à écrire naturellement quand on tape un fichier texte :
Titre de premier niveau ======================= Titre de second niveau ----------------------
Emphase
Pour mettre en gras et en italique (enfin, <strong> et <em> pour être exact), Markdown utilise indifféremment les étoiles et les underscores. Si on en utilise un seul de chaque côté du texte, ça donne de l’italique ; avec deux de chaque côté, ça fait du gras :
* italique * _ italique _ ** gras ** __ gras __
Avec Creole, on utilise toujours deux caractères spéciaux avec et après le texte. Pour l’italique se sont des slashes, pour le gras ce sont des étoiles :
// italique // ** gras **
Listes
Markdown permet d’écrire des listes non-ordonnées en utilisant les caractères étoile, plus ou tiret. Pour les sous-listes, il faut mettre 4 espaces en début de ligne.
* élément A * élément B * élément B.1 * élément B.2 * élément C + élément A + élément B - élément A - élément B
Du côté de Creole, la syntaxe se fait à base d’étoiles uniquement, et les sous-listes se font en ajoutant des étoiles supplémentaires.
* élément A * élément B ** élément B.1 ** élément B.2 * élément C
Pour les listes ordonnées (numérotées), Markdown impose de mettre un numéro en début de ligne, suivi d’un point :
1. élément A 1. élément B 1. élément B.1 1. élément B.2 1. élément C
Creole utilisé le caractère dièse pour les listes ordonnées :
# élément A # élément B ## élément B.1 ## élément B.2 # élément C
Liens
C’est là que ça commence à être vraiment différent. Markdown a une syntaxe − que je trouve bizarre − qui impose de mettre le titre des liens entre crochets, suivi de l’adresse du lien entre parenthèses :
[Google Reader](http://google.fr/reader)
Creole utilise une syntaxe basée sur des doubles crochets. L’adresse du lien vient en premier (car obligatoire) ; un caractère « pipe » peut être utilisé pour faire suivre le titre du lien :
[[http://google.fr/reader]] [[http://google.fr/reader|Google Reader]]
Images
Avec Markdown, l’insertion d’image est identique à l’insertion de lien, avec juste l’ajout d’un point d’exclamation devant, et le texte alternatif de l’image remplaçant le titre du lien :
Suis-je le seul à trouver cette syntaxe franchement nase ?
Avec Creole, la syntaxe est là aussi dérivée de celle des liens, en utilisant des accolades à la place des crochets :
{{http://url/vers/le/logo|mon logo}}
Texte préformaté
L’écriture de code préformaté se fait en Markdown par l’ajout de 4 espaces en début de ligne :
Exemple de code :
function toto() {
// ...
}
Dans Créole, cela se fait par l’utilisation de triples accolades :
Exemple de code :
{{{
function toto() {
// ...
}
}}}
Là, pour une fois, je ne trouve pas la syntaxe Créole très bien pensée. Dans tous les cas, j’ai été habitué à la syntaxe MediaWiki, qui impose simplement un espace en début de ligne.
Tableaux
Bizarrement, il n’y a pas de syntaxe (du moins, pas de syntaxe officielle) pour faire des tableaux avec Markdown. La documentation indique qu’il faut écrire le code HTML :
<table> <tr> <td>foo</td> </tr> </table>
Creole prévoit une syntaxe à base de caractères pipe :
|=titre col 1|=titre col2| |cellule 1 |cellule 2 | |cellule 3 |cellule 4 |
Je trouve dommage que Markdown ait laissé de côté cet usage. Mais je trouve aussi que la syntaxe Creole est très mauvaise. L’un des points fort de Creole − à mes yeux − est l’utilisation de double-caractères, car cela évite pas mal de problèmes. Là, pour les tableaux, j’aurais préféré une syntaxe utilisant des double-pipes. Sans compter que la syntaxe “pipe-égale” pour les en-têtes de tableau (équivalent aux balises <th>) est vraiment pas terrible − la justification étant que le égale est déjà utilisé pour les titres, ce qui est vrai mais n’apporte rien dans ce contexte.
Les autres éléments
J’ai passé en revue les éléments les plus courant que l’on attend d’un système de balisage léger. En tout cas, ce sont ceux dont j’ai besoin au quotidien.
Je ne parle pas des lignes horizontales (tag <hr/>), de la gestion des paragraphes ou de l’échappement des caractères spéciaux, qui existent dans les deux langages avec des différences minimes. Je dois reconnaître que Markdown propose une gestion assez pointue des paragraphes, notamment au sein des listes. Je dois dire aussi que c’est un besoin que je n’ai jamais eu en 10 ans…
Pour conclure, je pense que mon avis est assez clair. Je préfère la syntaxe de Creole à celle de Markdown ; je la trouve plus claire et plus lisible. Surtout, je me suis moins souvent retrouvé à devoir échapper des séquences pour qu’elles ne soient pas prises en compte (grâce aux double-caractères, qui évitent la plupart des séquences qu’on peut trouver naturellement dans du texte).
En fait, quand je suis tombé sur Creole, j’y ai trouvé ce que je cherchais alors depuis longtemps : une version simplifiée et homogénéisée de la syntaxe MediaWiki.
Je ne comprends toujours pas comment Markdown s’est répandu tel une traînée de poudre à travers le web. Si quelqu’un peut m’éclairer sur ce mystère, je suis preneur. J’ai toujours pensé que sa killer feature réside dans ses titres, dont les deux premiers niveaux peuvent s’écrire de la manière dont les titres ont toujours été écrits dans les fichiers textes depuis la nuit des temps (en les soulignant avec des caractères égale ou des caractères tiret). Est-ce cela qui lui a suffit pour s’imposer ?
L’une des plus grosses critiques que j’adresse à Markdown est sa documentation officielle. On dirait un site de warez, pas un site sérieux qui est référencé par des sites aussi majeurs que StackOverflow ou GitHub. C’est vraiment bizarre, parce que j’aurais tendance à penser qu’il est très difficile d’imposer quelque chose comme une norme lorsque c’est mal documenté. Il faut toutefois remarquer des initiatives récentes qui cherchent à améliorer la documentation de Markdown, tout en voulant standardiser les ajouts et améliorations du langage ; notamment Jeff Atwood, qui en parlait sur son blog et qui a la possibilité de fédérer pas mal d’énergies sur le sujet.
Au final, j’utilise Creole sur GitHub (cf. le projet FineFS). Mais pour mes projets personnels, j’ai fait quelques modifications pour pallier à ce que je considère comme étant des scories (et oui, ça me fait bizarre de remettre en question le boulot de toutes les personnes qui ont travaillé sur Creole). Un jour ou l’autre, je publierai peut-être ma version, on verra.
Je suis plutôt un inconditionnel de Markdown, et je trouve surtout dommage que les formats soient aussi bâtards et disparates : MediaWiki, DocuWiki, BBCode, Creole, Markdown… Déjà que pour un jeune ingé c’est lourdingue de se trimballer avec autant de syntaxe, alors l’intégration à grande échelle dans un SI avec des outils dédiés à tout le monde, bonjour le bordel quand il faut justifier la diversité !
Tu parlais des tableaux, il existe une notation en markdown souvent reprise par la plupart des interpréteurs :
| titre A | titre B | titre C |
——————————
| foo | bar | foobar |
| possibilité de span 2 colonnes || blah |
Oui, mais cette syntaxe (pour les tableaux) est tributaire d’une extension, certes répandue, mais pas officielle.
Est-ce que tu peux expliquer pourquoi tu es un inconditionnel de Markdown ? Par rapport aux équivalents ? Ça m’intéresse d’avoir ton avis, parce que comme je l’ai écrit, j’ai du mal à comprendre pourquoi il est si réputé, alors qu’il existe des équivalents plus anciens avec les mêmes fonctionnalités.
On est d’accord que la multiplication de formats est dommage. Mais tant qu’il y aura des gens qui se diront inconditionnels de l’un plutôt que de l’autre, alors que les différences sont globalement minimes, on en reste au même point 😉
Boutade mise à part, on devrait être capable de passer facilement de l’un à l’autre.
Au final, il y a deux approches que j’aime bien : Celle de GitHub, qui supporte plusieurs langages de formatage (et qui explique comment en ajouter d’autres), et celle des multiples systèmes de wiki qui supportent un langage commun (Creole) en plus de leurs langages natifs.
Ce sont deux solutions différentes à un même problème, deux solutions intelligentes et satisfaisantes.
Ma préférence pour Markdown est très personnelle, rien de bien rationnelle et se justifie assez bien par ton article : j’insère peut-être une ou 2 images par articles/page, mais souvent beaucoup de code. Du coup, c’est celle que j’ai retenu pour Github et fatalement pour les autres services quand c’est disponible.
Pareil pour les listes, j’ai du mal avec la lisibilité offerte par Creole… Par contre, je dois avouer que si les tableaux ne sont pas disponibles facilement, ça pourrait changer la donne…
PS: Je ne savais même pas que Github gérait les 2 !
Yep, GitHub supporte 9 formats différents. Pas mal !
Pour les listes, Creole réutilise exactement la même syntaxe que MediaWiki. J’y suis habitué depuis très longtemps, donc c’est difficile pour moi de faire la part des choses. Mais on ne peut pas dire que ça ait porté préjudice à Wikipedia 🙂
(mauvais argument, on est d’accord, vu qu’il y a quand même des trucs un peu caca dans la syntaxe MediaWiki)
Il y a un détail important dans le GitHub flavoured Markdown : le fait qu’il soit impossible de mettre en italique une portion d’un mot. Parce que dès que tu écris des trucs qui contiennent des underscores, c’est habituellement une vraie plaie avec Markdown ; obligé de tout échapper. C’est là que les double-caractères de Creole font souvent la différence.
J’utilise pour ma part énormément Markdown, pour plusieurs raison :
0. La syntaxe est très intuitive pour un grand utilisateur du courriel : blocs de citation (beaucoup plus courants que des tableaux), emphase avec un ou deux dièses, listes avec des tirets ou des chiffres…
1. La syntaxe est vraiment conçue pour faciliter la relecture. Dans mon cas (j’écris au sein d’un collectif et on se relit les uns les autres), c’est plus que nécessaire.
2. La gestion des paragraphes. Je ne pourrais pas m’en passer.
3. La grande liberté dans la syntaxe : tu as déjà parlé des titres, mais ça s’applique à l’emphase, aux listes, etc. En fait, ce n’est pas pour rien si Markdown a été inventé par un développeur Perl, il y a pour presque chaque chose plusieurs possibilités. Résultat, on adapte la syntaxe à notre texte et non l’inverse. Un exemple ? En orthotypographie française, chaque élément d’une liste non ordonnée commence par un tiret semi-cadratin. En orthotypographie anglaise, c’est une puce qui commence ces éléments. Résultat, j’utilise le tiret pour mes listes non ordonnées dans un texte en français et le plus pour mes textes en anglais ; la relecture m’est plus agréable.
4. Les liens. Vraiment. En fait je pense que tu as mal compris : ce qu’il y a entre crochets dans ton exemple n’est pas le contenu de l’attribut xHTML `title` mais le texte sur lequel le lecteur cliquera. Ainsi, `[texte](http://url.tld)` est équivalent de `<a href= »http://url.tld »>texte</a>` et `[texte](http://url.tld « title »)` est équivalent de `<a href= »http://url.tld » title= »title »>texte</a>`. Mais il y a, il est vrai, plus simple pour la relecture. Markdown propose ce plus simple : la syntaxe de liens dits « référencés ». Le fonctionnement est simplissime.
0. Au sein de notre texte, l’on place nos liens accompagnés d’une référence : `[texte][ref]` ;
1. hors de tout paragraphe, l’on renvoi nos références vers un URL éventuellement accompagnée d’un titre : `[ref]: http://url.tld « title »` ;
2. l’interpréteur génère exactement le même lien qu’avec la syntaxe en ligne, c’est lisible et il y a un bonus : si l’on lie plusieurs fois la même page, une seule référence suffit pour un nombre illimité d’appel à cette référence !
Tu noteras aussi que cette syntaxe de liens référencés est si utilisée qu’elle a inspiré de très nombreux interpréteurs alternatifs. Ainsi, la première fonctionnalité ajoutée, bien avant les tableaux, c’est les notes de bas de pages ! PHP Markdown Extra, l’interpréteur que j’emploie pour mon blog, ajoute aussi la gestion des abréviations selon ce même principe : un régal.
5. Les listes ordonnées numérotées. Note comme il est agréable de repérer immédiatement où l’on se trouve dans une longue liste… Bien plus propre que des dièses, non ?
6. &c. Je trouve régulièrement de nouvelles raisons d’aimer cette syntaxe que j’utilise pour écrire des courriels, des commentaires (comme ici), des nouvelles, des scénarios de court-métrages ou de bandes dessinées, des documents de travail internes à mes associations voire carrément des documents à valeur juridique (statuts, contrats… — avant passage dans Pandoc pour en faire du ODF que j’exporte en PDF) ou plus simplement pour noter mes cours (oui, je suis *aussi* étudiant ;)).
Voilà. J’espère avoir répondu à la question du pourquoi tant de gens aiment tant cette syntaxe 😉
Merci pour cette explication détaillée. C’est intéressant. J’ai quand même quelques questions et remarques.
1. Je prends ce point.
2. Tu parles des paragraphes seuls (si je puis dire), ou la gestion des paragraphes à l’intérieurs des listes par exemple ? Parce que pour le premier c’est la même chose que les autres systèmes équivalents, et je n’ai personnellement jamais eu besoin du second.
3. C’est totalement repris de reStructuredText, ça. Moi j’y vois plutôt un inconvénient. Justement comme les langages de programmation qui permettent de faire la même chose de 3 milliards de façon différentes, on finit par avoir autant de conventions que d’utilisateurs. La charge cognitive nécessaire pour relire un document écrit par quelqu’un d’autre s’en trouve d’autant plus grande.
4. Si, si, j’avais bien compris comment fonctionnent les liens. Je persiste à trouver ça pas terrible du tout. Les liens référencés peuvent clairement être très pratiques dans certaines situations (principalement quand les liens sont utilisés plusieurs fois dans le même document) ; mais là encore, je ne pense pas que la syntaxe soit géniale.
Surtout, je ne pense pas qu’on puisse maintenir que la syntaxe des liens de Markdown respecte la philosophie du « c’est comme ça qu’on l’écrirait naturellement dans un fichier texte ». Et c’est encore plus marquant pour insérer une image.
5. Question de point de vue. Si tu retravailles souvent l’ordre de tes listes, tu devras faire un choix entre trois possibilités. Soit tu prends le temps de rénuméroter dès que tu changes l’ordre. Soit tu gardes la numérotation, qui ne veut alors plus rien dire. Soit tu finis par mettre le numéro “1.” devant tous tes items.
J’avoue ne pas avoir d’avis ultra tranché sur ce qui est préférable. Dans un fichier texte destiné à être relu tel quel, on aurait tendance à renuméroter à la main. Mais je vois dans les langages de balisage léger un moyen d’édition rapide plus qu’un moyen de relecture rapide.
En tout cas, encore merci pour ton commentaire. Je crois déceler que la gestion des paragraphes de Markdown est l’un de ses gros points forts.
Content d’avoir lu cet article. Je ne connaissais pas ces différentes chapelles de syntaxes.
Pour le reste, je reconnais dans Créole les principes de ce que j’utilise tous les jours avec le wiki interne que nous utilisons : http://www.jspwiki.org/ . Celui-ci est basé sur Creole, tout en apportant quelques améliorations, qui d’ailleurs me font penser à celles que tu aimerais voir dans Créole, si j’ai bien compris. Je conseille donc d’y jeter un oeil.
Pour le reste, je ne comprend pas ce que tu repproches à l’affichage du code entre crochets. Je trouve ça très simple, d’autant qu’il est hérité d’une hierarchie entre crochets (en ligne, pour afficher du code, on peut n’utiliser que 2 crochets de chaque coté dans JspWiki).
Pour les tableaux, effectivement, je ne comprend pas très bien d’où sort le |= même si je me dis que c’est un pipe de tableau + un égal de titre (celui pour les titres de markdown) donc on obtient un titre de tableau… Pour ça, jspWiki fait simplement une hierarchie de pipes : 2 pipe pour une cellule de titre, 1 pipe pour une cellule classique.
2. Des paragraphes seuls, dans les listes, dans les blocs de citation…
3. C’est bien possible mais j’ai connu reStructuredText après Markdown. Les deux sont plutôt élégants et agréables à utiliser, mais il me subsiste une préférence pour cette dernière. Sans doute une question d’habitude, mais pas que… cf. les points 0 et 2 de mon précédent commentaire.
Par ailleurs, comme c’est conçu pour être lisible, ce n’est pas très dérangeant de voir plusieurs conventions en fonction de l’utilisateur. La syntaxe reste suffisamment simple comme ça. Par contre, il est vrai que ce doit pas mal compliquer la vie de ceux qui développent les interpréteurs…
4. Je comprends ce point de vue, mais comment écris-tu naturellement un lien (sauf en donnant l’URL dans le corps du texte, ce qui est rarement ce que l’on souhaite faire) ? Personnellement j’ai tendance à considérer le pipe comme moins naturel qu’un crochet, que l’on a tous utilisé au moins une fois en cours de maths au secondaire…
5. C’est vrai que je n’ai pas pensé à ce point. Peut-être parce qu’il est rare (au moins pour moi) de réordonner une liste ordonnée, et que donc la réécriture à la main ne me dérange pas tant que ça… Cela dit, je suis persuadé qu’il doit bien exister un moyen de réorganiser nos listes automatiquement. Je vais travailler un petit script quand j’en aurais le temps… Merci pour l’idée !
Par contre j’insiste sur la relecture, partie intégrante d’une édition efficace. Mon enseignant de philosophie des arts (je suis étudiant en arts) me disait un jour que le bon écrivain se doit d’être schizophrène, pour à la fois se placer dans la peau de l’écrivain et de celle du lecteur… Un propos plein de sagesse que j’entends honorer (sauf quand je suis fatigué 😉 bonne nuit !)
@Louis : Rien d’étonnant, le développeur principal de JSPWiki était au Wiki Markup Standard Workshop de 2006 🙂
Quand tu parles de crochets, j’imagine que tu veux parler des accolades. Hum, la syntaxe des triples accolades me semble quand même moins simple que les espaces en début de ligne de MediaWiki.
Les tableaux à base de pipe simple me gênent car, comme pour toute syntaxe à base de caractère unique, le risque est grand de mauvaise interprétation. C’est aussi ce qui me dérange avec la syntaxe des liens de JSPWiki (ainsi que celle des liens externes de MediaWiki).
@al.jes : En fait, je n’achète pas l’idée que Markdown est un format parfait pour écrire du texte avec mise en page qui puisse se lire aussi naturellement qu’un fichier texte. Et c’est valable pour tous les systèmes de balisage léger (ainsi que, évidemment, ceux qui ne sont pas légers).
Ça fonctionne pour les trucs de base, comme les titres, les paragraphes, les blocs préformatés, … Mais dès que tu veux aller un tout petit peu plus loin (liens, images, tableaux, notes de base de page, blocs de code, …) ça ne marche plus.
J’ajouterais que même avec le système le plus simple, une majorité des gens sont incapables d’interpréter eux-même le rendu et on besoin d’une fonctionnalité de prévisualisation.
J’en reviens à mon point précédemment évoqué : pour moi l’enjeu est plus de me permettre d’éditer rapidement que de relire facilement (même si ça doit rester un objectif, on est d’accord).
Relire sans édition => autant utiliser le rendu généré
Relire avec édition => on a besoin d’une prévisualisation, à moins d’écrire juste des titres et des paragraphes
Quelques exemples :
– Les quelques personnes que je connais qui utilisent Pandoc basent toujours leur relecture sur le résultat final. Ça me semble assez logique, c’est aussi ce que je fait quand j’édite du HTML, du LaTeX ou que j’écris une page de man avec POD.
– Sur ce blog, les gens peuvent utiliser un sous-ensemble minimal du HTML, pour insérer des liens, mettre en gras ou en italique. L’usage de base reste d’écrire du texte en paragraphes. J’ai quand même ajouté un plugin de prévisualisation des commentaires, parce que ça m’avait été demandé plusieurs fois.
– Je ne pense pas qu’on puisse dire que la syntaxe MediaWiki ait nui au succès de Wikipedia. On est d’accord que cette syntaxe peut être assez complexe, mais uniquement parce qu’elle permet de faire des choses que peu d’autres langages équivalents peuvent faire. Pour les fonctionnalités communes, ça reste très semblable.
– J’utilise énormément Trello. Mais je ne compte plus le nombre de fois où je me suis arraché les cheveux, simplement parce que des underscores ou des étoiles sont interprétés en dépit du bon sens. Je me retrouve donc à alterner entre l’édition et le rendu, pour m’assurer que tout passe bien. D’où ma critique générale à tous les systèmes basés sur des caractères simples, qui ont plus de chance de se retrouver naturellement dans un texte. Et d’où ma remarque sur le fait que Markdown n’est pas magique au point de retirer le besoin de prévisualisation.
– Je suis d’accord que l’écriture de listes numérotées est plus lisible avec Markdown qu’avec Creole. Mais juste pour nuancer la chose, je dois dire que j’écris beaucoup plus de listes non ordonnées que de liste ordonnées. Et que (dans l’idée que l’important est pour moins d’éditer rapidement), la syntaxe à base de dièses est bien plus rapide à saisir. Il y a beaucoup de choses dans Markdown qui sont basées sur la présence d’indentations sur 4 espaces, ce qui est long à saisir (moi ça me saoule) et peut générer des erreurs (là, il y a 7 ou 8 espaces ?) surtout lors de copier-coller.
– Pour finir, si le besoin est de pouvoir relire et modifier rapidement et facilement, il existe de très bons éditeurs WYSIWYG, comme celui de GitHub. Sur mes projets personnels, je préfère me passer d’éditeur WYSIWYG, parce que je vais plus vite à utiliser une syntaxe wiki-like que de cliquer sur des icones. Mais si l’enjeu est de retravailler continuellement un document (à plus forte raison de manière collaborative), le WYSIWYG est vite incontournable.
OK pour la complexité des liens ou des images, ce pourrait être mieux. Pour les blocs de code, c’est en revanche simplissime : un bloc entièrement indenté dont l’indentation ne dépend pas d’une liste ? c’est un bloc de code. Quant aux notes de bas de page, ça n’est pas dans le Markdown de base, mais voici ce que propose PHP Markdown Extra pour cet usage : `[^#]` (où le dièse est un nombre) là où tu veux ton numéro en exposant et `[^#]: Ta note` en fin de document. Bref, si ce n’est pas lisible…
Quant à la prévisualisation, les gens avec qui je travaille, pas forcément informaticiens (pas du tout informaticiens d’ailleurs) n’ont pas de problème de lecture (hormis pour les liens ou images, mais ils comprennent quand je leur explique) et donc n’utilisent presque jamais de prévisualisation (bien que je leur ai montré comment faire et qu’ils soient capables de le faire sans mon aide). À l’expérience, Markdown remplit donc plutôt bien son objectif de lisibilité. J’utilise Pandoc, mais pas pour la relecture, seulement pour l’étape finale de mise en page. Ainsi je peux en premier lieu me concentrer sur le fond et ça a tendance a beaucoup plaire à mes collaborateurs (cette séparation entre fond et forme). Pareil pour le WYSIWYG, qui bien que séduisant au premier abord, est vite délaissé par ceux à qui je montre Markdown, sans que je les force aucunement. Est-ce dû au concept de syntaxe légère ou à des qualités propres à Markdown ? J’imagine qu’il doit y avoir des deux, puisque je n’ai jamais vu quiconque utiliser la syntaxe MediaWiki pour des projets personnels alors qu’ils l’utilisent sans problème sur Wikipédia.
Et puisqu’on en parle, où ai-je dit que MediaWiki aurait pu nuire à Wikipédia ? Les gens s’adaptent au contexte en général assez bien… Je n’ai tâché ici que d’expliquer pourquoi je préfère Markdown et pourquoi cette dernière me semble préférée des néophytes, jamais je n’ai voulu taper sur d’autres syntaxes, qui ont leur utilité (sinon elles n’existeraient pas).
Ta critique des caractères isolés est intéressante mais il ne faut pas non plus que la syntaxe s’alourdisse de trop. Il y a un compromis à trouver (ou plutôt, au vu de la profusion de syntaxes déjà existantes, c’est aux utilisateurs de choisir celles qu’ils préfèrent). Personnellement, cela ne me dérange pas plus que ça et je n’ai pas constaté de dérangement particulier dans mon entourage… J’en parlerai à mes collaborateurs, pour voir.
Idem pour les listes, cela dépend surtout de l’usage de l’utilisateur… C’est un avantage de plus pour les syntaxes proposant une liberté dans la façon d’écrire 😉 Petite précision néanmoins pour les indentations de quatre espaces : c’est quatre espaces (ou plus) ou une tabulation de plus que le niveau précédent pour des blocs de code, mais seulement deux espaces (ou plus) ou une tabulation pour les listes… Pour les différents paragraphes d’un bloc de citation, l’on répète le `> `. Et surtout, c’est toujours par rapport au niveau d’indentation précédent. Ça se passe donc très simplement sans beaucoup de questions de la part de l’utilisateur…
Oui, je sais bien que tu n’as pas critiqué MediaWiki. Je répondais juste en même temps à tes remarques et à ce que j’ai pu lire sur le web 🙂
Je comprends ton point, pas de soucis. On a sûrement des expériences différentes.
Encore une fois, je vois d’un côté des gens qui ont besoin de prévisualisation rien que pour des paragraphes, et de l’autre côté je vois ma propre utilisation dans Trello, où je souffre dès que je veux placer un fragment de code (underscores) ou une expression mathématique (étoiles) dans du texte, ce qui m’arrive assez souvent l’air de rien. Entendons-nous bien, j’ai trouvé Textile encore pire.
Bref, agree to disagree. 🙂
Au passage, tu dis que personne n’utilise la syntaxe MediaWiki pour des projets personnels. Certes… mais moi je connais plus de personnes qui se sont installés un MediaWiki perso que de personnes qui utilisent Markdown pour autre chose qu’écrire un readme sur GitHub. 😉
(mais d’un autre côté, mes amis sont des geeks, ce n’est pas représentatif de grand-chose)
Personne dans mon entourage, nuance… J’ai vu en revanche de nombreux projets libres avec leur documentation en MediaWiki donc je me doute que ça existe (la preuve).
Ensuite, pour les expressions mathématique, c’est vrai que ce n’est pas un usage courant pour moi… Sans compter que soit j’utilise une vraie syntaxe mathématique avec des « +–×÷ » et non « +-*/ », soit j’utilise la syntaxe de tel ou tel langage et donc c’est du code (et Markdown prévoit ça)… Donc ça ne m’a pas beaucoup dérangé. Mais je comprends parfaitement qu’un utilisateur courant de ce genre de contenus ne peut pas se permettre de chercher des caractères spéciaux à toutes les sauces.
Merci pour l’article. Pour les tableaux au format markdown, je suis étonné sur le fait d’avoir besoin d’un plugin. Partout où j’ai utilisé les tables, cela à fonctionné. Donc apparemment tout les devs sont sympa avec nous.
P.S : Sur mac, j’utilise l’application Mou qui est vraiment confortable. http://mouapp.com
Bonjour. Je préfère la syntaxe Creole sur les listes, les titres, les emphases. Cependant, trois points :
1. Je ne trouve pas la syntaxe pour les éléments « blockquote » en syntaxe Creole ?
2. Une chose que je trouve intéressante dans la syntaxe MarkDown : chaque ligne de texte reste toujours détachable du reste par copier-coller et la syntaxe conserve un sens. Le système des triples accolades en Creole pour le non-formatage casse ce principe. Et l’idée de MarkDown était pourtant futée : si on a du code, c’est qu’on a un éditeur de développeur et alors un simple surlignage + TAB ajoute la tabulation.
3. Le line-break MarkDown est intuitif pour tout le monde et en fait une syntaxe utilisable par des non informaticiens, idéale pour des commentaires de blog notamment. Celui de Creole (le double anti-slash) est nul.
En fait la syntaxe idéale serait :
– Creole pour les titres, les listes et les éléments en ligne emphases, liens, images ;
– MarkDown pour les blocs de citation, les blocs de code et les line-break.
En ajoutant un paramètre du type « 123x456em » pour définir la taille des images.
@Cpag : Merci pour ton commentaire. Mes réponses :
1. Effectivement, c’est un gros manque de la syntaxe Creole. Dans ma version modifiée, j’ai ajouté le support du caractère supérieur (>) pour les citations, comme dans MediaWiki et Markdown.
2. Ce que tu dis est vrai pour du code source, c’est vrai (idem pour la syntaxe MediaWiki, d’ailleurs). Par contre, dès que tu utilises la syntaxe des tableaux, des « liens référencés » (cf. les commentaires de al.jes) ou des notes de bas de page, je ne pense pas que ça fonctionne…
3. Je suis d’accord que le double-backslash est pas terrible. Mais terminer une ligne avec deux espaces a un gros soucis : on ne le voit pas dans un éditeur de texte. On pourrait dire que c’est voulu, mais ça reste bancal. D’ailleurs, il suffit de voir que la plupart des syntaxes dérivées de Markdown (ne serait-ce que celle de GitHub) gère les retours-chariots en les transformant directement en <br />.
Oups ! J’aurais dû vérifier la syntaxe MarkDown réelle. Je pensais que le retour charriot signalait un line-break. C’est le retour charriot comme passage à la ligne qui est intuitif pour tout le monde !
Concernant la syntaxe des tableaux et des notes de bas de page, j’ai l’intuition que c’est précisément parce que ces fonctionnalités impliquent un contexte sur plusieurs lignes qu’elles n’ont pas été intégrées dans la syntaxe MarkDown.
En effet, le double espace de fin de ligne est ce que j’ai comme plus gros reproche vis à vis de Markdown. Mais on trouve assez souvent des interpréteurs comprenant le simple retour charriot et, au pire, on peut s’y faire, donc je ne suis pas très véhément sur ce point…
Amaury, en quoi as-tu implémenté ta modification ?
Dans quelques mois j’aurai besoin d’un parseur JavaScript de syntaxe Wiki. Nous pourrions collaborer pour fabriquer un « MarkCreole » qui reprendrait le principe « une ligne-un contexte » de MarkDown et celui du doublage des marqueurs de Creole. Nous pourrions, tant qu’à faire, doubler les pipes des tableaux et implémenter une solution de notes de bas de page.
Ma version est implémentée en PHP, et utilise le projet WikiRenderer comme base, sur lequel j’ai défini ma syntaxe.
Pour le coup, je ne suis pas trop fan du « une ligne-un contexte », parce qu’il y a de toute manière des blocs multi-lignes dont il faut prendre en compte les spécificités.
Si j’avais le temps (soupir), je publierais ma syntaxe et le code associé. Et au passage j’ai un certain nombre d’évolutions en tête qui mériteraient d’être implémentée.
Bon, je ne vais pas apporter grand chose au moulin de la conversation puisque je ne connaissais pas du tout Creole et mon utilisation est autre. Disons que ce sera le point de vue d’un amateur lambda.
Je suis arrivé à Markdown par Markdown Extra de Fortin pour WordPress – très bonne documentation au passage. Ce ne suis donc pas codeur mais rédacteur de billets de blog. L’apprentissage a été ultra rapide – il n’y a que les notes de bas de page dont j’oublie la syntaxe. Je n’utilise jamais les tableaux ni les images – aucun des langages ici ne peut gérer les classes CSS utiles pour la mise en page et il faut rester au HTML direct.
Il y a un truc que j’aime bien dans Markdown et que je n’ai pas vu listé ici: le passage à la ligne sans saut (deux espaces à la fin de la ligne – pas très lisible je le reconnais et je me demande s’il y a une équivalence Creole).
Quand au questionnement sur le succès de Markdown, il ne faut pas trop chercher: il suffit que quelques personnes influentes l’utilisent et c’est parti – le public ne va pas s’amuser à tester tous les langages du même type. Le monde de la technologie et du Web est plein d’exemples de langages ou technologies considérés comme pas les plus « beaux/efficaces » qui ont fini par s’imposer sur la concurrence (ne parlons pas des Arts). C’est comme ça, il faut l’accepter.
Trois ans après la rédaction de ce billet, on peut remarquer qu’il existe plusieurs freewares qui permettent de prévisualiser en live du Markdown (notamment Markdown Edit ou MarkdownPad) et WordPress a intégré les bases de Markdown dans l’édition de billets.
Je plussoie pour les tables: les deux ont une syntaxe pas pratique… a noter que la syntaxe des double pipe est celle de pmwiki, et evite bien des confusion.
L’aspect le plus naze (et le plus gonflant, de loin, sur github et stackoverflow) est le quadruple espace pour les zone de code ou préformatées… C’est très pénible a éditer, d’autant plus que les éditeurs en ligne ne font pas de retour à la ligne intelligent… donc soit on édite à coté et on copie-colle, soit on se retrouve à compter les espaces (vu que tabulation, l’éditeur en ligne il ne gère pas non plus). Dans les deux cas c’est nul. La syntax MediaWiki avec un seul espace est bien plus pratiques.
Mais globalement, c’est Markdown ça reste très fragile, et il faut basculer sans cesse sur la prévisualisation, alors que le doublement de caractère à la Creole évite la plupart des ambiguités.
Après tout ce temps, ce billet reste toujours d’actualité et vrai ! Les différents commentaires apportent de l’eau au moulin du billet ; et je vais rebondir sur certains d’entre eux.
Je rejoins la remarque selon laquelle utiliser l’indentation pour marquer les listes (et les blocs de code) est très lisible (l’alternative proposée par WikiCreole n’est pas vraiment moins lisible/clair, mais fait beaucoup plus condensé/dense à la relecture mais plus pratique quand on se retrouve à réorganiser de longues listes…) Cependant parfois casse bonbon quand on travaille en ligne et qu’on se retrouve à perdre du temps à compter les espaces et même faire de la prévisualisation…
CPag, les triples accolades, bien que cassant en apparence la simplicité sont une pratique courante pour ceux qui parsèment leur texte d’extrait de code. (c’est courant, dans les newsgroups, à une certaine époque, d’utiliser le balisage BBcode ou une autre convention pareillement) C’est d’ailleurs le principe utilisé par MarkDown avec les triples apostrophes inversés.
La syntaxe des tableaux dans Creole est symple et hélas pas en accord avec l’usage plus solide de doubles symboles. Les extensions Mark utilisent une syntaxe similaire, car cela correspond à la façon dont on fait simplement les tableaux dans un mail (au format texte, lu avec une police à chasse fixe) : ça reste dans l’esprit (MD ayant été créé en se basant sur les pratiques dans les échanges par mails au format purement texte)
Justement, dans les messageries je n’ai pas trouvé mention de la façon de faire les liens de MD… Les gens mettent directement le l’adresse ; ou le mettent soit entre parenthèses (OK ça ça peut venir de là), soit entre chevrons d’inégalités (conformément aux RFC), et le texte associé est entre guillemets doubles (et non entre crochets droits, réservé pour préciser ou annoter –était-ce l’idée de MarkDown ?)
Le point fort de Creole est malheureusement aussi sa faiblesse : les symboles doubles sont fastidieux pour les nouveaux venus, mais ils permettent de ne pas avoir les surprises qu’on a de l’autre côté (personnellement, il m’arrive souvent d’avoir des mots avec des blancs soulignés ou underscores et/ou des astérisques, et de devoir rééditer pour les échapper là où il faut.)
Il y a beaucoup à dire, et pour avoir pratiqué les deux (et d’autres systèmes de balisage léger), je comprends qu’on puisse s’épandre du MD (et mis à part pour les liens et images, ainsi que pour les titres par soulignement alors que je préfère utiliser ces traits comme des filets horizontaux) cela correspond quasiment à la façon dont j’écris les mails (j’avoue que je n’utilise pas toujours l’indentation pour les listes) Pourtant, dès qu’on a à écrire du contenu plus riche, on se rend compte que c’est vite limité et qu’il faut recourir au pure HTML là où avec Creole je n’ai jamais eu le besoin. Mais bon, l’adoption par des plateformes comme SlashDot et les forges a établi le moins bon format comme un standard.