Markdown est un convertisseur qui transforme du texte « brut » en code XHTML. C’est une alternative aux éditeurs WYSIWYG qui ne s’adaptent pas forcément à tous les besoins. Markdown vous permettra de rédiger des textes en utilisant un format de balisage de texte simple à écrire et à lire, puis à le convertir en code XHTML (ou HTML en option) structurellement valide. A première vue, la syntaxe utilisée est très proche de celle que vous utilisez peut-être si vous rédigez sur des wikis. A première vue, car Markdown est bien plus puissant, surtout si l’on utilise PHP-Markdown Extra…
Markdown, comment ça marche ?
La création d’un paragraphe se fait simplement en sautant une ligne. Pour créer une liste ordonnée ol, il suffit de commencer une liste comme suit :
1. Premier élément de liste 2. Deuxième élément de liste 3. Troisième élément de liste, etc.
Pour les listes non-ordonnées ul, il suffit de remplacer les chiffres par les symboles -, * ou + au choix :
- Premier élément de liste - Deuxième élément de liste - Troisième élément de liste, etc.
Vous me direz, oui, mais avec l’éditeur WYSIWYG de WordPress, il suffit de cliquer sur l’icône prévue dans l’éditeur pour arriver au même résultat… Certes, mais l’intérêt de Markdown est d’autoriser certaines imbrications de balises difficiles à obtenir avec un éditeur WYSIWYG, comme avoir des paragraphes p ou des citations blockquotes à l’intérieur des éléments de listes li :
- Premier élément de liste - Deuxième élément de liste - Troisième élément de liste, etc.
Le fait de sauter une ligne à chaque entrée de liste créera donc une balise p à l’intérieur des balises li, ce qui peut-être utile. Si vous désirez tester Markdown sans pour autant faire une installation, vous pouvez vous entrainer en ligne.
Les plus 🙂
La documentation sur la syntaxe est complète et on s’aperçoit que la complexité apparente de certaines combinaisons n’est que l’expression de la souplesse de Markdown qui propose souvent plusieurs façons pour parvenir au même but.
Cerise sur le gâteau, le script Markdown s’installe aussi comme plugin pour WordPress et peut à première vue être utilisé en même temps que l’éditeur visuel (à tester en profondeur quand même).
Les moins 🙁
Les listes de définition que j’utilise régulièrement ne sont pas prises en charge. Toutefois, le fait de pouvoir mélanger la syntaxe Markdown et le XHTML rend cet inconvénient moins critique.
Par ailleurs — et ça sera certainement un détail pour beaucoup de monde — mon enthousiasme est freiné par le fait que tout texte commençant par le symbole # devient un niveau de titre h1 et entre en collision avec mes nombreux exemples de feuilles de style CSS qui font la part belle à ce même symbole pour qualifier les identifiants. Mais encore une fois, la souplesse de Markdown permet d’utiliser le symbole backslash pour « échapper » les caractères « gênants ».
Markdown reloaded avec PHP Markdown Extra
S’il est possible d’utiliser du HTML à côté de la syntaxe Markdown, il n’est pas possible d’intercaler du code HTML pour formater du texte placé dans une balise div, par exemple. Heureusement, Michel Fortin a eu la bonne idée de commettre PHP Markdown Extra qui ajoute une palanquée de fonctionnalités au script d’origine :
- Listes de définition,
- Attribut id dans les titres pour faciliter la création de d’ancres internes,
- Syntaxe pour créer des tableaux HTML très facilement,
- Création aisée de notes de bas de page,
- Support pour la création d’abréviation (abbr),
- Etc.
En prime, vous trouverez la traduction française de la documentation de la syntaxe Markdown, ce qui vous permettra de gagner du temps !
Pour conclure
Markdown est une solution très intéressante pour ceux qui veulent garder une certaine maitrise sur le code XHTML de leurs billets et/ou permettre aux commentateurs d’enrichir leurs contributions (une option permet de désactiver le parsing des commentaires), sans qui soit nécessaire d’être geek pour celà : avec un effort de formation minimum et un peu de bonne volonté, je pense que le grand public peut s’approprier cet outil. Pour ma part, le temps de tester PHP Markdown Extra plus avant et de modifier mes exemples CSS, et je n’utilise que ça 😉
Mmm faut que je test ça, ma plus grande crainte avec plugin étant que ça ressemble à un parseur à l’affichage donc un truc capable de bouffer de la ressource à tour de bras et de considérablement ralentir un blog…
Intéressante présentation en tous cas, ça me donne envie de l’essayer ! 😀
Bonjour,
Finalement on risque vite de se retrouver avec la syntaxe « Wiki ».
Concernant une « une alternative aux éditeurs WYSIWYG », Amaya : http://www.w3.org/Amaya/ ?
Hey, content de voir que tu creuses la question. 😉
J’avais écrit un petit billet dans ce sens il y quelques temps aussi :
http://www.sqliagency.com/blogs/ecreativegarden/index.php?2008/02/18/92-markdown-et-smartypants
Comme le dit burningHat : si c’est un parseur à l’affichage, ça risque de ralentir le bazare.
Par contre si ça parse avant d’enregistrer en base, ça peut aller.
Mais comment retrouver la syntaxe markdown pour éditer un billet publier avec cette syntaxe ?
Avec un parser inverse: xhtml to markdown ?
A voir au niveau des performances.
En tout cas ça ressemble fortement à de l’écriture wiki, donc pour peu que les utilisateurs en aient l’habitude, l’adoption en sera plus simple.
Jeff Atwood sur HTML vs Markdown vs Textile :
http://www.codinghorror.com/archives/001116.html
@burningHat, @loïc m. > la question des performances n’est pas superflue, mais je me dit qu’au pire, ça peut justifier l’installation d’un système de cache, vous en pensez quoi ?
@20cent > la question de l’éditeur idéal me taraude depuis pas mal de temps et jusqu’à présent j’ai toujours préféré le marquage html, mais markdown pourrait bien me faire changer d’avis 😉
@Bibinou > Ce comparatif est intéressant et comme je le disais juste au-dessus, jusqu’à présent le html avait ma préférence.
Ce qui manque au comparatif, c’est la notion de lisibilité et de portabilité car l’auteur semble mettre Textile, Wikipedia, BBCode et Markdown au même niveau alors qu’il n’y a pas photo : markdown est le seul qui reste vraiment lisible, ou du moins qui utilise une syntaxe qu’on a tous plus ou moins utilisé à l’époque des machine à écrire pour structurer des textes (ok, pas tout le monde, mais c’est juste une question de génération 😉 )
PS : j’ai activé markdown, donc à priori il devrait y avoir quelque problème dans les exemples CSS des billets. Mais vous pouvez tester directement la syntaxe dans les commentaires pour vous faire la main 😉
Moi, ce qui me stresse, c’est que le plugin ne soit plus suivi dans une version future de WordPress. Retoucher tous mes billets, ça fait un peu peur :-))
C’est juste une fonction en php les gars hein, pas à proprement parlé un plugin. 🙂
@Nicolas > je viens de repêcher ton commentaire dans les spams, bienvenue !
@Li-An > en fait, comme le fait remarquer 20cent, il s’agit avant tout d’un script qui semble être fait pour durer puisque la dernière version de l’auteur d’origine date de 2004 et que des mises à jour ont été réalisées en 2008.
Par ailleurs, le projet Markdown semble suffisamment répandu pour que le script ne soit pas abandonné.
Pour ce qui est des performances évoquées par @burningHat et @loïc m. j’ai jeté un oeil dans la base de données et c’est bien le xhtml converti qui s’y trouve : la syntaxe est bien parsée qu’une seule fois ! (enfin, j’attends que les pros me confirme tout celà 😉 ) ce qui fait qu’il n’y a pas d’inquiétude à avoir quant à une éventuelle retouche des billets déjà rédigés.
Merci pour ces précisions:-) J’avoue que j’aime beaucoup Markdown et je ne pensais même pas à l’utiliser dans les commentaires !
Pour information, Movable Type 4 propose Markdown en natif. Et règle la question du parsing à l’affichage vu que le comportement «standard» de Movable Type est de générer des pages HTML statiques.
Je n’ai pas bien compris à quel problème tu faisais allusion pour tes exemples CSS ? S’il s’agit de citer un sélecteur au sein d’un paragraphe, par exemple
#sidebar ul li, ça va tout seul. Et pour un bloc de code:/* Ici tout mon bloc de code CSS */
On peut faire la même chose directement, il me semble, en commençant une ligne par un certain nombre d’espaces (au moins quatre espaces, ou une tabulation).
Quant à l’intérêt de Markdown, je dirais que :
Pour un utilisateur ayant une bonne connaissance de HTML, Markdown ne présente pas un avantage radical sur l’utilisation de HTML (avec peut-être quelques automatismes comme la création de paragraphes, par exemple).
Je pense que pour former sérieusement un utilisateur ne connaissant pas ou peu HTML à un outil de publication web, c’est une solution intéressante. Je pense ici à un rédacteur amené à intervenir fréquemment sur un site à fort contenu rédactionnel, pas au patron de PME qui mettra peut-être le nez un jour dans le back-office de son site (mais peut-être pas). L’utilisation d’une autre syntaxe textuelle simple, telle que MarkDown ou le wiki2xhtml de Dotclear (j’estime à l’inverse que la syntaxe textuelle de MediaWiki ou la syntaxe Textile ne sont pas suffisamment claires), permettent à l’utilisateur de créer facilement des titres, des listes et des liens. Le reste est un peu moins évident, et sera exploité par les plus à l’aise. Mais rien que l’utilisation des listes et titres, ou la création de liens pertinents, sont des avancées qui sont aujourd’hui difficiles à obtenir avec un éditeur Wysiwyg. Ces derniers ont souvent ces fonctionnalités (encore que, pour les titres ça n’est pas toujours vrai!), mais elles sont rarement perçues par les utilisateurs.
Pas une solution miracle, mais quelque chose d’intéressant malgré tout.
(En passant, tu as un problème avec le style de tes éléments CODE, dont je rappelle que ce sont des éléments de type en-ligne et non pas de type bloc, ainsi qu’avec le rendu des listes dans les commentaires… too much resetting, uh?)
Oki, alors si c’est parsé une seule fois puis écrit en base ça soulève une autre inquiétude : c’est récupérable sans que WordPress foute son bazar habituel si tu as crée un billet avec un code un tant soit peu complexe ? 😉
Parce que si c’est du « one shot » pour écrire ces billets ça serait presque mieux un parser d’affichage + un bon cache en effet :p (je sais que ça fait gros chieur mais ce sont de vraies questions, promis !)
salut,
Markdown est un super plugin. Je l’utilise sur mon blog depuis un bout de temps, principalement parce qu’il permet aux commentateurs de formater facilement leurs commentaires…
à bientôt !
@Florent > Yep, merci, c’est réparé. J’avais oublié de styler le contenu des commentaires (un effet de bord du resetting, effectivement…).
Par contre, je ne sais pas si ça vient de Markdown ou de WordPress, mais les balises PRE CODE /CODE /PRE sont mises dans un paragraphe dans la source du commentaire. Paragraphe qui se tranforme en paragraphe vide, à l’affichage…
Sinon, pour avoir testé pas mal d’éditeurs non wysiwyg, Markdown est le seul que je trouve lisible et facilement compréhensible par un rédacteur non technicien à condition qu’il y trouve un gain de temps.
Par exemple, j’utilise maintenant Markdown AVEC l’éditeur de WP et pour faire des liens, rien ne vaut le clic sur l’icône des liens.
Pour ce qui est des éléments en ligne comme EM, STRONG, je suis un peu partagé : dans certains cas, il est plus rapide de sélectionner une portion de texte et de cliquer sur l’icône, parfois, non. Ca dépend un peu de la manière dont on anticipe la mise en forme (pardon, la sémantique qu’on met derrière ;)) )
En revanche, pour les listes UL, OL, DL, les tableaux ou les ancres internes, le fait de rendre une url ou une adresse mail cliquable, etc. il n’y a pas photo : Markdown fait des miracles.
Ce qui m’intéresse surtout, c’est le fait de pouvoir mettre très facilement des paragraphes dans les listes, système que j’emplois régulièrement pour distinguer les simples énumérations des listes avec plus de texte pour que ça soit plus lisible.
C’est aussi un filet de sécurité contre les éventuels problèmes de fermetures de balises oubliés, ce qui arrive souvent, surtout quand les billets sont longs 😉
@burninHat > je n’ai pas bien compris ce que tu entends par « récupérable » ? Tu veux dire lorsque tu veux éditer le billet à nouveaux ?
@LOmiG > oui, maintenant, je me souviens avoir lu ce billet. A l’époque, je cherchais juste un éditeur wysiwyg parfait… J’ai compris maintenant que ça n’existe pas ;))
salut Bruno,
moi c’est pour la section commentaire que j’en cherchais un. et j’en ai testé un paquet pour insérer juste « gras », ‘italique » et « liste à puces » dans les options des commentaires. Aucun n’est au niveau de Markodown, qui présente, dans cette utilisation spécifique, le problème de ne pas être avec des boutons et de demander à l’utilisateur lambda d’aller lire un mode d’emploi avant…
oui, la perfection n’existe pas…
LOmiG, il faut tout simplement développer un plugin qui propose un petit éditeur avec boutons pour insérer la syntaxe Markdown (ou autre, d’ailleurs) dans les commentaires.
Bon, il faut savoir coder un minimum en PHP, et pas mal en Javascript. Et ça prend du temps. Mais d’autres se sont peut-être penchés sur la question?
Je reviens ici pour dire que le plugin en question existe désormais. Il s’appelle Markdown on Save et enregistre le billet tapé en HTML pour une meilleure réaction dans le rendu. Mais je suis à la recherche d’un moyen pour transformer tous mes vieux billets en html parce que les deux plugins ne fonctionnent pas en même temps 🙁
Li-An — C’est une excellente nouvelle, merci d’être revenue la partager avec nous 🙂