Limites, normes et standards

“Si l’argument de la simplicité revient dans toutes les discussions sur les avantages du Markdown, à l’opposé, toutes les critiques convergent vers les difficultés inhérentes à sa non standardisation. Avec l’évolution exponentielle de la publication numérique, en ligne ou non, le Markdown devient populaire comme langage d’écriture et de publication, quelle que soit la spécialisation du rédacteur : les différentes variantes du Markdown, souvent nommées flavor (parfum, ou saveur), de manière assez suggestive, entérinent cette évolution. En l’absence d’une direction donnée par son fondateur, le Markdown ouvre la porte à une multitude de variantes qui l’éloignent autant de l’interopérabilité, chacune ajoutant ses spécificités à la norme déjà bancale de l’original. L’un des développeurs les plus avancés dans l’évolution du Markdown a même mis au point, en guise de test, une application permettant de mesurer les différences entre les 22 versions connues du langage, qu’il nomme babelmark, en référence à l’épisode biblique. (Mpondo-Dicka, 2020)”

Depuis sa création, et encore actuellement, Markdown fait donc face à de nombreuses critiques dont essentiellement la multiplication des variantes, l’absence de normes liées à Markdown et sa légèreté, voire sa simplicité.

Variantes

En matière de multiplication des variantes, en effet, en 2013, Martin Fenner[1] parlait déjà de 31 flavor, saveurs, pour Markdown (“31 flavors is great for ice cream but not markdown”). Mpondo-Dicka (2020) de son côté, en 2020, cite 22 variantes. Depuis, BabelMark[2] décline jusqu’à 35 variantes.

Les différences sont parfois minimes d’une variante à l’autre. Elles sont créées par des communautés afin d’adapter Markdown à leurs besoins et à leurs outils. Les quatre déclinaisons du CommonMark[3] présentées plus haut restent les principales variantes.

La syntaxe de base qui s’applique aux titres, aux listes, aux formatages simples (gras, italique…), aux liens et aux images reste toujours la même dans les différentes variantes.

Normalisation

En matière de standardisation, malgré l’intérêt indéniable de Markdown, il n’y a toujours pas de norme qui y est associée. Néanmoins, “Markdown s’est imposé comme une forme de standard de fait (Fauchié, 2024)”.

Le CommonMark[4], dont la rédaction des spécifications techniques : https://spec.commonmark.org/[5] a débuté en 2014 (dernière mise à jour en janvier 2024), est loin d’être généralisé et ce n’est d’ailleurs toujours pas une norme.

L’idée est aussi que Markdown puisse être uniquement considéré comme un outil, orienté structuration sémantique de contenus, pour la création de pages web et de documents dans des formats divers et variés. C’est donc un format “technique” qui permet le développement de technologies. Dès lors, considérant que html, pdf, ePub, Docx, odt et autres font l’objet de normes et standards, pour d’aucun, le problème ne se pose pas vraiment.

Néanmoins, en mars 2016, dans le but de standardiser le langage, deux RFC (appel à commentaires) ont été publiés (source Wikipedia[6]) :

  • RFC 776314, qui introduit le type MIME text/markdown à partir de la variante originale de Markdown.
  • RFC 776415, qui répertorie des variantes MultiMarkdown, GitHub Flavored Markdown (GFM), Pandoc, CommonMark, Markdown Extra et autres (source Wikipedia).

Ici encore, le travail est en cours.

Simplicité

Enfin, à propos de la légèreté et de la simplicité de Markdown, il faut revenir au point de départ et relire la présentation de John Grubert[7] en 2004 :

Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

Pour Mpondo-Dicka (2020)

“Le Markdown correspond donc à un certain nombre de besoins d’écriture que son développeur a implémenté dans un script : écrire, relire et mettre en forme sans effort des articles publiés en ligne au format HTML ; c’est pourquoi Gruber néglige certains aspects de l’écriture qui ne lui sont pas utiles (notes, table des matières…). Plus encore, il n’a que faire de la standardisation de son langage : le HTML est le standard, le Markdown n’est qu’un outil pour en faciliter l’écriture.”

Cette simplicité était bien un objectif en soi. Si la “critique” concerne le CommonMark[8], pourquoi pas mais depuis lors et particulièrement quand Pandoc, associé à LaTeX, est apparu, cette critique a perdu tout son sens et les documents produits avec ces outils n’ont plus rien à envier à ceux des traitements de texte, lorsqu’ils sont bien utilisés.

Pour voir ce qui est possible, consultez par exemple le rapport du projet AcOBE[9], dont le sujet est proche de celui du présent manuel et dont le processus d’édition et de publication est basé sur Markdown avec les logiciels Pandoc et LaTeX .

  1. sur son blog : https://blog.front-matter.io/posts/what-flavor-is-scholarly-markdown/ ↵
  2. https://babelmark.github.io/?text=%23+titre%0A ↵
  3. Markdown Extra, Github Markdown, Vanilla Flavored Markdown et MultiMarkdown, le Pandoc-Markdown étant une déclinaison de ce dernier. ↵
  4. https://commonmark.org/ ↵
  5. Ce travail destiné à corriger les erreurs et imprécisions du Markdon d’origine est réalisé par une petite équipe, soutenue par GitHub, Stack Overflow, Stack Exchange, Reddit, Discourse et LinuxFr.org et pilotée par John MacFarlane, le créateur de Pandoc. John Gruber et Aaron Swartz n’y sont pas associés. ↵
  6. https://fr.wikipedia.org/wiki/Markdown ↵
  7. https://daringfireball.net/projects/markdown/ ↵
  8. https://commonmark.org/ ↵
  9. https://orbi.uliege.be/bitstream/2268/312724/1/rapport_final_AcOBE.pdf ↵

Licence

Symbole de Licence Creative Commons Attribution 4.0 International

L’écriture académique au format texte avec Markdown et Pandoc Droit d'auteur © par Bernard Pochet est sous licence Licence Creative Commons Attribution 4.0 International, sauf indication contraire.

Partagez ce livre