Markdown, Markdown Everywhere

Mer 19 février 2014

Le web, c'est essentiellement du texte. Quasiment tout est fondé sur un échange de messages en mode texte, de la demande d'une URL à un serveur, de la réponse renvoyée au format HTML en passant par les feuilles de style, le Javascript, etc. Quand on envoie un formulaire sur un site, c'est également du texte qui transite au travers de la méthode POST ou GET. Et c'est encore du texte qui sous-tend cet ensemble au travers des entêtes HTTP, des codes d'erreur, etc. Les seuls contenus non-textuels seront les images et les contenus multimédia.

Pour peu qu'on soit un peu instruit dans les arcanes des normes du W3C, en gros, il suffit de savoir lire pour comprendre ce qui se passe entre un navigateur et un serveur web.

Finalement, le seul inconvénient dans tout cette textualisation, c'est qu'au moment ou Dédé Lulu va vouloir fournir du contenu dans un site internet, on va lui demander d'entrer le tout au format HTML. Dès lors qu'il aura envie de mettre quelque chose en gras ou en italique, d'insérer une image ou un lien... On sort des 26 lettres de l'alphabet et on entre dans le monde des balises HTML.

Tu <em>vois</em> ce que je <strong>veux dire ?</strong>

Dédé Lulu n'y connaît rien en HTML. Et c'est tant mieux, d'ailleurs. Le HTML, c'est des règles bizarres, une grammaire certes cohérente, mais impénétrable au profane. Et il va être difficile d'expliquer à Dédé Lulu pourquoi on ne peut pas insérer simplement un lien sans parler a, href et des chevrons qui doivent s'ouvrir ou se fermer dans l'ordre.

Alors les développeurs web, dans leur infinie bonté, ont essayé de créer des éditeurs de texte un peu plus intelligents que leurs vimacs et ont offert le What You See Is What You Get: un éditeur qui cause presque la lange de Dédé Lulu, avec des boutons pour mettre du texte en forme, insérer un lien, etc.

Et le cauchemar des développeurs, au lieu de s'arrêter, a continué.

Pour faire court, ces éditeurs sont rapidement devenus des usines à gaz, des bordels sans nom, des machines à problèmes.

Le format Markdown est d'une simplicité limpide. Il est celui qui se rapproche le plus du format texte brut, en ajoutant quelques formules magiques de premier niveau (on est très loin du balisage HTML), on peut très facilement mettre en forme un texte. Insérer une image. Ajouter des titres sur plusieurs niveaux.

Pour s'en convaincre, il suffit d'aller jeter un oeil à la documentation originelle, où John Gruber a jeté il y a bientôt 10 ans les bases d'un format qui est en passe de s'imposer comme un standard de fait pour tout document textuel.

Markdown est partout, tout autour de moi. J'écris ce post pour Je Hais Le Printemps en Markdown, format que j'ai adopté par défaut depuis plusieurs années, sauf cas exceptionnel. J'écris la documentation de mes projets en Markdown, ma documentation personnelle (sur un micro wiki perso), les jeux que j'écris, les essais, les nouvelles, les romans (non, je déconne, j'ai abandonné l'écriture de romans, mais tu vois le tableau).

Même mes présentations sont écrites selon ce formalisme minimaliste.

Son ubiquité vient de sa simplicité. Avec quelques toutes petites règles de mise en forme, n'importe qui peut produire un document Markdown qui reste lisible (ses astérisques et ses parenthèses ne gênent pas la lecture). Mais aussi et surtout : il peut être transformé en HTML extrêmement facilement. En HTML ou en tout autre format, d'ailleurs. Parce qu'il est facile à "parser" (comprendre, analyser), on arrive à générer à peu de frais du HTML valide, qu'on style comme on veut, comme on a envie.

La simplicité du balisage a une autre vertu : on économise de la place. Au lieu de se trimballer une énorme balise strong, on a juste deux astérisques. Pour les liens, c'est pareil. Pour les balises images aussi.

Bref, less is more.

Markdown est également extensible. On aura besoin de bidouillages pour monter des tableaux, rajouter des notes de bas de page, etc. Mais Dédé Lulu n'aura vraisembablement pas besoin de ces raffinements.

Markdown est partout.

C'est le format par défaut du géant Github en ce qui concerne la documentation des projets (README ou wiki). Le service Gist.io convertit un texte Markdown en HTML en utilisant un style plutôt lisible.

Pandoc, l'outil qui convertit TOUS LES FORMATS les uns vers les autres, utilise Markdown comme format en entrée par défaut.

Les commentaires du site d'entraide StackOverflow sont en Markdown.

Bientôt feu Editorially permettait la saisie de documents Markdown en ligne.

Pelican, Jekyll, Octopress... Autant de moteurs de génération de site utilisant Markdown comme format de contenu initial (la plupart sont capables d'utiliser d'autres formats, mais je gage que le plus utilisé reste Markdown).

On trouve pléthore d'éditeurs de texte orienté Markdown, sur toutes les plateformes et même en ligne.

Il n'y a guère que chez les Pythonistes que la documentation est sous format reStructuredText, principalement à cause de Sphinx. C'est vrai que ce générateur de documentation est très bien fait, mais des alternatives commencent à fleurir, à base de Markdown.

Mais... en fait, Markdown n'est pas vraiment partout. On le trouve enfoui dans les entrailles des sites internets, ou au fin fond d'une base de données. Mais si on réfléchit bien, le résultat, ce qu'on lit, ce qu'on a vraiment dans la fenêtre du navigateur, ça reste du HTML. Quoi qu'on ait écrit, si on veut que le browser web, aussi moderne qu'il soit, nous le donne à lire, il aura fallu passer par une étape de moulinage et de transformation en HTML. Et par le biais des feuilles de styles, on rendra ce contenu aussi élégant que lisible. Mais on aura perdu le fichier source, l'origine, le vrai signal primitif.

Le texte arrive, avec sa cohorte de balises encombrées. Alourdi. Apesanti.

Je propose une chose : qu'on donne la possibilité aux navigateurs web de lire directement du Markdown. Dans le browser. Sans étape de prémâchage du côté du serveur. Sans transformation avant d'être envoyé au navigateur.

Mais attention, il convient de ne pas donner à lire du Markdown. Dédé Lulu serait choqué de ne pas pouvoir cliquer sur un lien, par exemple. Mais disons que la transformation du format brut en format intelligible se ferait dans le navigateur, à la volée.

C'est pour cela que je propose qu'on invente un mimetype, un nouveau Content-Type : text/markdown.

J'y vois plusieurs avantages :

  • le navigateur pourrait mouliner le HTML et lui appliquer une feuille de style par défaut. Rien n'empêche les créatifs et designers de cette planète de nous fournir des feuilles de styles personnalisées et personnalisables. Même contenu brut au départ, mise en forme "custom". Ou pas.
  • Évidemment, la mise en page "de base" serait un peu austère. Pas de menu, pas de bandeau aux couleurs de l'éditeur du site... qu'à cela ne tienne ! rien ne nous empêche de fournir dans les entêtes HTTP un certain nombre de gabarits HTML que le navigateur peut aller piocher, pour l'intégrer aux contenus. Double avantage : une fois le gabarit téléchargé, il peut être mise en cache et réutilisé pour les autres pages du site qui l'utilisent.
  • moins de bande passante entre le client et le serveur. En fonction de la complexité du document, on pourrait économiser une bande passante assez considérable. Imagine deux secondes les gains entre les serveurs de Wikipedia et les navigateurs si on virait les balises de rendu HTML pour se concentrer sur le contenu. Et uniquement le contenu.
  • Les auteurs de contenu n'auront pas à se faire suer à rédiger selon un format qui devra être remâché par l'équipe d'intégration ou par l'outil de gestion de contenu. Apprendre à écrire du Markdown est à la portée de n'importe qui, et le contenu rédigé peut être directement utilisé par le site. La tâche de la rédaction est facilitée.

Je n'ai aucune idée de la faisabilité de ce rêve.

Mais j'ai très très envie qu'il devienne une réalité.

Qui est prêt à m'aider ?