De la simplification à outrance du workflow

• Date : 2023-10-04
• Auteur : Tim
• Tags : sémantique, névrose

À l’origine, j’étais comme tout le monde, je cherchais à simplifier au maximum mon workflow et j’en suis venu sans trop réfléchir à opter pour un convertisseur Markdown → HTML. Cette période est désormais révolue et je prends un certain plaisir à naviguer dans la doc’ en ligne de Mozilla à la recherche de la balise parfaitement adaptée à chaque situation.

Oui mais Condor HTML et Markdown ne sont pas antinomiques. Ces deux approches sont conciliables, on peut écrire du HTML _inliné_ dans du Markdown !

🆗🆒 mais pourquoi rajouter une _build-step_ en plus pour générer les 3 pauvres balises <h1> de vos articles de minable. Soyons sérieux, le HTML est largement autosuffisant et assez peu verbeux dans ses moutures modernes. Il y a littéralement une trentaine de cas où le balise fermante <p> peut être omise.

https://html.spec.whatwg.org/multipage/syntax.html#optional-tags

Maintenant que je vous ai fait descendre de la tour de Babel à générer de dette technique en haut de laquelle vous vous étiez hissés, évoquons les problèmes récurrents de Markdown.

La manière dont les gens se servent du Markdown est fondamentalement incorrecte

Markdown ne comprend rien à ce que vous écrivez. Je m’explique, considérez le document suivant :

>Mignonne, allons voir si la rose
>Qui ce matin avoit desclose
>Sa robe de pourpre au Soleil,
>A point perdu ceste vesprée
>Les plis de sa robe pourprée,
>Et son teint au vostre pareil.
>
>Las ! voyez comme en peu d’espace,
>Mignonne, elle a dessus la place
>Las ! las ses beautez laissé cheoir !
>Ô vrayment marastre Nature,
>Puis qu’une telle fleur ne dure
>Que du matin jusques au soir !
>
>Donc, si vous me croyez, mignonne,
>Tandis que vostre âge fleuronne
>En sa plus verte nouveauté,
>Cueillez, cueillez vostre jeunesse :
>Comme à ceste fleur la vieillesse
>Fera ternir vostre beauté.

Pierre de Ronsard, _Les Odes_

qui est équivalent en HTML à :

<blockquote>
  <p>
    Mignonne, allons voir si la rose
    Qui ce matin avoit desclose
    Sa robe de pourpre au Soleil,
    A point perdu ceste vesprée
    Les plis de sa robe pourprée,
    Et son teint au vostre pareil.
  </p>
  <p>
    …
  </p>
  <p>
    …
  </p>
</blockquote>

<p>
  Pierre de Ronsard, <em>Les Odes</em>
</p>

On remarque plusieurs problèmes :

• Personne ne comprend rien ;
• Mort de la sémantique ;
• Les gens comprennent uniquement grâce au rendu : Markdown devient une sorte de CSS light ;
• T’es hors sujet avec tes balises éparpillées gros.

Observez plutôt :

<figure>
  <blockquote>
    <p>
      Mignonne, allons voir si la rose
      Qui ce matin avoit desclose
      Sa robe de pourpre au Soleil,
      A point perdu ceste vesprée
      Les plis de sa robe pourprée,
      Et son teint au vostre pareil.
    <p>
      …
    <p>
      …
  </blockquote>

  <figcaption>
    Pierre de Ronsard, <cite>Les Odes</cite>
  </figcaption>
</figure>

On remarque :

• Ne demande pas foncièrement plus d’efforts pour une personne digne ;
• Soigneusement écrit ;
• Vrai ;
• Beau ;
• Juste.

Les bibliothèques Markdown génèrent n’imp

Un autre exemple, avec ce bout de Markdown :

<p>
  Foo

  Bar
</p>

La majorité des lib’ produiront un code HTML équivalent à :

<p>
  Foo

  <p>
    Bar
  </p>
</p>

Ce qui est, je vous le donne en mille, du HTML malformé, avec tous les problèmes en matière de composabilité que cela engendre, ℯℊ corrompre le rendu d’un lecteur RSS qui comptait sur votre rigueur pour faire son job correctement.

On pourra toujours objecter :

Oui mais Condor ce ne sont pas des problèmes liés au Markdown en soi, c’est juste les librairies que tu utilises qui sont à chier.

🆗🆒 bah faites-mieux alors.

Le Markdown n’est spécifié nulle part

Utiliser Markdown ? Ok mais quelle version ? Le « vanilla » tel que penser par feu Aaron Swartz ? Le GitHub flavored ? Celui qui permet de générer une table des matières automatiquement mais pas d’écrire des tableaux ?

Vous comprenez où je veux en venir : cette jungle est insupportable. Certes CommonMark se veut être une solution mais il arrive un peu après la guerre car sorti initialement en 2014 (c’est-à-dire la même année que HTML5 et plus de 10 ans après Markdown).

https://daringfireball.net/projects/markdown/syntax
https://commonmark.org/

Études de problématiques sous-jacentes

• C’est super chiant à parser Markdown putain. En comparaison, HTML est quasiment du XML. On sait le parser depuis 25 ans ;
• Du fait des raisons énumérées plus haut, Markdown pour l’accesibilité c’est à chier.

Conclusion

Écrivez du HTML, vous éviterez de vous tirer une balle dans le pied. Continuez d’utiliser Markdown pour vos readme niais de projet à 2 stars mais pas pour cibler un rendu HTML.

Tant qu’à faire, s’il vous plaît de grâce, arrangez-vous pour que votre HTML soit valide, par exemple en utilisant le vérificateur en ligne du W3C et laissez-vous bercer par cet agréable écran :

En plus, vous écoperez d’un badge mignon qui ajoutera un charme certain à vos pages Web :

https://www.w3.org/TR/badging/

Bonus

Lors de l’écriture de cet article, je suis tombé sur cet intéressant thread qu’on peut résumer assez trivialement par :

Faites des outils pour rendre HTML agréable au lieu de perdre du temps avec du Markdown abruti

https://merveilles.town/@neauoire/111154810425383324

Un dernier mot

Oui, on utilise Gemtext pour le blog, c’est encore pire que Markdown mais au moins le HTML de notre site est correct contrairement au votre. Vous pouvez d’ailleurs admirer nos efforts pour que le HTML généré par notre proxy HTTP fasse sens ici :
https://github.com/Psi-Prod/Proximite-2/blob/master/html_of_gemtext.ml

Je songe de plus en plus à générer statiquement une version HTML du site et simplement la serve comme on le fait pour Gemini mais Léo dit que je suis un con.

Retour au gemlog
Retour à l’accueil

Commentaires (1)

Écrire un commentaire

Par Anonyme, le 11 octobre 2023 :

Je suis assez d'accord avec le fond, mais écrire du code (à afficher, à coup de <pre> et de <code>) dans du HTML, c'est une plaie !