je ne peux que plussoyer : j'ai toujours détesté les limitations de Markdown. Je connais peu asciidoc, mais ça sera toujours mieux que markdown. https://txt2tags.org/ me semblera toujours le top du top, la syntaxe semble tellement tomber sous le sens (c'est quasi la même que Creole qui a produit une documentation abondante sur les raisons de tel ou tel autre choix)…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
la syntaxe semble tellement tomber sous le sens (c'est quasi la même que Creole qui a produit une documentation abondante sur les raisons de tel ou tel autre choix)…
Exactement, la raison pour laquelle je dis que la syntaxe Wiki est mieux fichue (en plus d'être plus riche de base) que Markdown ! Malheureusement, il y a beaucoup de dialectes qui ont l'avantage d'être plus riche que Creole (mais n'est-ce pas le même souci avec toutes les « saveurs » de l'autre qui font que je ne peux pas juste prendre mes écrits pour Github ou Gitlab et les mettre sur Linuxfr juste pour prendre cet exemple.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
J'aurais bien voulu faire adopter AsciiDoc(tor) à mes collègues car je le trouve très avantageux pour faire bien des choses mais un élément rédhibitoire à une adoption générale est la création de tableaux. C'est une caractéristique qui me semble commune à tous ces langages de documentation en "plain text" mais la différence se fait avec un éditeur WYSIWYG.
Personnellement, j’ai un peu de mal avec la syntaxe des tableaux d’Asciidoc(tor) pour avoir pas mal joué avec.
Je trouve que les différentes caractères à utiliser pour configurer les trucs comme l’alignement, la taille des colonnes, etc. ne sont pas intuitif à l’utilisation (un seul caractère n’est pas suffisamment descriptif, l’ordre des caractères change tout d’une manière relativement arbitraire de prime abord, c’est pas facile de comprendre ce que ça veut dire si on revient dessus plus tard, etc).
C’est en fait mon plus gros reproche à Asciidoc que je trouve sinon excellent, mais cette syntaxe est déjà plus permissive et plus simple que celles du Markdown de toute manière.
Je suis fan du combo Emacs + OrgMode pour ce qui est des tableaux. J’ai été bluffé par la simplicité de création et d’édition des tableaux dans Emacs qui sont en plus très simple avec la syntaxe d’OrgMode.
En fait, OrgMode c’est même vraiment excellent, et j’ai tendance à favoriser ce format pour tout ce qui ne justifie pas carrément l’utilisation de LaTeX.
Je crois comprendre… Mais ces tableaux sont encore lpus basiques non ? https://orgmode.org/guide/Tables.html
…c'est comparabel aux tableaux du Markdown de Linuxfr ou GMF
…et si on a moins de fonctionnalité, c'est forcément plus simple. :-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Le reproche n'est pas lié à AsciiDoc spécifiquement mais aux formats de documents textuels (dont Markdown et Latex) pour lesquels les tableaux ne sont pas faciles à construire puis, lorsque le tableau est un peu volumineux, pas facile à relire. C'est, à mon avis, le point de réticence que peuvent avoir des utilisateurs qui sont habitués à du WYSIWYG.
Avec LaTeX, il existe plusieurs solutions pour gérer les tableaux, avec en particulier l'import du contenu à partir d'un fichier externe.
De plus, il suffit d'enregistrer les modèles choisis sous forme de snippets de code dans son éditeur préféré pour gagner du temps à la création de nouveaux tableaux.
Et c'est sans compter avec les possibilités de mise en page très étendues grâce aux extensions, par exemple des lignes de couleurs de fond alternées ou d'alignement des nombres que la virgule (avec SIunitx). Tout le contraire de Markdown, quoi.
Par contre, ce dernier est très pratique pour réaliser une mise en forme basique, et avec un css adéquat, on peut obtenir un résultat visuellement joli, et on peut même ajouter des maths avec Mathjax, mais pour les tableaux, c'est quasiment le désert.
Oui :-) Mais sa remarque initiale n'était pas sur la possibilité comme je l'avais cru aussi, mais sur la lisibilité et le bruit d'écriture avec les formatages textes : «
les tableaux ne sont pas faciles à construire puis, lorsque le tableau est un peu volumineux, pas facile à relire
» Pour que ton tableau soit lisible, il faut bien aligner le délimiteur de champs (& en LaTeX) et que les lignes ne débordent pas… et qu'il n'y ait pas pas besoin de formatage avancé (fusion de lignes ou de colonnes, justification spécifiques et changeantes, etc.) qui vont automatiquement ajouter du bruit dans le source. Pour le rendu, pas de souci : LaTeX et AsciiDoc permettent de faire de très belles choses avancées en y passant peu de temps (quand on maîtrise assez pour ne pas se perdre dans le marquage.)
Attention, le support des maths est comme pour les tableaux dépendant des dialectes Markdown utilisés. Tous n'utilisent pas Mathjax et pour ceux qui le font n'ont pas les mêmes options (par exemple ${mathjax} …(…)$` etc. mais aussi le support des équations chimiques qu'on n'a pas sur Linuxfr par exemple.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
que je trouve quand même plus avancés que Markdown
Markdown ne possède pas de tableaux du tout (à part en insérant du HTML brut). CommonMark ne corrige pas ce problème non plus. Ce sont quelques implémentations éparses qui proposent des tableaux, avec des syntaxes subtilement différentes.
Ça catalyse parfaitement tout ce pourquoi Markdown est très mauvais :
- trop simpliste, ne permet même pas des choses courantes comme des tableaux
- pas assez normé, fragmentation extrême, les implémentations sont incompatibles les unes avec les autres, CommonMark est là pour aider, mais uniquement sur la syntaxe de base qui est elle même mal normée
Un exemple de liste qui ne produit pas le même résultat partout :
foo:
- bar
Même CommonMark est instable et change trop d'une version à l'autre, cf une différence non-négligeable entre 0.28 et 0.29.
En soi, on peut dire qu'un « document markdown » est en fait très lié à une seule implémentation de rendu, celle choisie par celui ou celle qui a édité le document. En soi, markdown désigne bien trop de choses différentes. On devrait plutôt parler par exemple de « document Gitlab Markdown » ou « document CommonMark 0.30 », et ensuite veiller à ne pas tenter de le faire rendre sur une autre implémentation, sous peine d'avoir un rendu très mauvais.
Asciidoc est certes plus puissant, mais Ô combien moins accessible au non initié.
Rédiger de la doc, c'est déjà difficile de convaincre les gens, et d'arriver à leur faire faire. Si en plus ils doivent se poser des questions existentielles, c'est pas la peine de rêver. Le critère pour espérer avoir de la doc, c'est rendre ça le plus simple possible, tant pis si c'est au détriment des fonctionnalités.
Par contre, j'avoue que le manque de normalisation est un peu pénible. Quand on met du markdown dans une spec API (type OAS ou Swagger), c'est très chiant de jamais savoir comment ça sera rendu au final (sachant que chaque portail API peut interpréter ça légèrement différemment).
Posté par raphj .
Évalué à 3.
Dernière modification le 20 juillet 2022 à 09:06.
L’avantage c’est que Markdown c’est tellement pauvre pour écrire de la doc qu’il n’y a pas beaucoup de questions à se poser justement ! (/s)
Plus sérieusement, je préfère avoir une syntaxe un peu plus compliquée et ne pas tomber sur des limitations en pleine rédaction de doc. Moi c’est plus ça qui peut me faire sortir du « flow ». De toute façon, on finit par connaitre les éléments de syntaxe après un peu de pratique, mais la limitation, elle, ne s’en va pas. Et je préfère devoir chercher un peu comment faire quelque chose (j’ai l’habitude, j’ai pratiqué LaTeX…) que me rendre compte que ce n’est pas possible et devoir compromettre. Parfois, compromettre donne un meilleur résultat, mais parfois, c’est juste casse-pieds.
Et Markdown, tu finis par devoir connaitre les petites subtilités et limites de chaque implémentation, donc ce n’est pas si simple.
On est d'accord :-) C'est juste que j'avais à l'esprit que quand la syntaxe est simple, on a moins d'interrogations et au début j'en avait quand même pas mal avec Markdown (comparé aux syntaxes Wiki et Asciidoc.) Plus tard, j'ai continué à me poser des questions parce-que pendant longtemps je n'ai pas compris que c'était juste limité et qu'il fallait pas chercher (sinon on perd des heures pour découvrir que ce n'est pas possible) et faire des compromissions un peu étranges et peu satisfaisantes. Encore beaucoup de questions quand on se préoccupe de la portabilité : si je n'écris que pour Linuxfr, pas de soucis ; si j'espère réutiliser le même sur Medium ou dans mon Gitea ou autre, ça va être la prise de tête pas drôle.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Au final quelque soit la foece de asciidoc comparé à markdown en terme se fonctionnalités, ça ne vaut rien une fois qu'on prend en compte l'adoption bien meilleure de ce dernier dans une foultitude d'outils.
Je suis d’accord, mais je tiens à noter que la plupart des forges de code supportent nativement Asciidoc, autant que le Markdown.
Ça ne présente donc quasiment aucun inconvénient de l’utiliser dans un dépôt hébergé sur des plateformes comme Github, Gitlab, Codeberg (ou n’importe quelle instance Gitea)…
Pour ce qui est du reste, les outils utilisant le Markdown (l’éditeur de LinuxFR!, discourse et autres) pour des trucs relativement basiques sont plutôt compatible avec Asciidoc (enfin… l’inverse!) qui fait de gros efforts pour ressembler à Markdown sur les trucs de base (équivalence entre les = et les # pour indiquer les niveaux de titre, gestion du markup de base similaire, etc).
J’ai l’impression que les subtilités entre Markdown et Asciidoc deviennent importantes sur des éléments plus complexes (images, blocs de code, tableaux) ou sur des cas où Markdown peut être ambigü (imbrications de styles).
Du coup, il me semble qu’apprendre le Asciidoc permet plus ou moins de se servir du Markdown quand même ! :-)
Pas vérifié pour les autres, mais Github supporte aussi ReStruturedText : comparé à Asciidoc c'est tout aussi puissant mais moins compatible Markdown.
Concernant les outils disponibles, le lien mentionne justement le fort couplage entre un site/plateforme et une appli, le format n'est pas portable/pérenne pour de la doc. Les reproches faits à Markdown peuvent se résumer dans l'absence de marquage/structuration évolué/complexe et beaucoup d’ambiguïté pour des choses quand même simples.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Mais est-ce vraiment pertinent. De ce que j'ai lu de l'article la plupart des exemplea de fonctionnalités mentionnés font plus partie de la catégorie "bon à avoir" que "indispensable".
J'ai rarement besoin d'utiliser des balises html parce que je me sens limité avec markdown. Je crois que la seule que j'utilise un peu régulièremnt est la balise dans une cellule de tableau pour avoir des rwtours à la ligne dans une cellule.
Et je trouve que les grosses limitations de markdown m'imposent de faire du contenu sobre ce qui n'est au final pas plus mal.
Ah et la seule chose qui m'a retenu l'attention dans les exemples de l'article, c'est l'inclusion s'un bout de code via une directive include. De prime abord tu te dis "cool" plus besoin de faire des copier/coller…puis tu réfléchis un peu et tu te dis que si tu fais ça ton markdown ne peut plus bouger ou tu vas péter le lien, tu pourrais avoir des incohérences entre ce que dit la doc et l'exemple dans le code block parce que tu as modifié le code, etc, etc. Et cela sans que tu ne t'en rendes compte si tu ne vas pas vérifier. Et au final ce sont ces vérifications et changements qui te coûtent plus qu'un pauvre petit copier/coller dans le cycle de vie de ta documentation.
Assez récemment encore j'en ai eu besoin, de mettre du balisage HTML dans le dernier journal que j'ai pondu ici. :-) Rien que d'utiliser des tableaux montre déjà que tu es confronté aux grosses limitations de Markdown car ce n'est pas de base (tu utilises un ajout qui n'est garanti de fonctionner dans tous les dialectes et donc n'est pas portable.) ;-) Ce que tu appelles contenu sobre, pour moi ce sont surtout des commentaires (comme j'ai dit dans un autre commentaire)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Mouais les tables sont supportées par toutes les implémentations que j'ai pu utiliser donc c'est devenu un standard de fait.
Pour les balises dans ton journal, tu parles des balises ? Je n'ai pas bien saisi pourquoi tu les as utilisé en fait et en quoi ton journal n'aurait pas été lisible et sémantiquement correct sans elles. Et en général si je veux une police mono dans un bout de markdown sans être dans un bloc se code j'utilise les backticks (`backticks`) et si je veux représenter des touches uniques je le fait comme cela abc ( `a` `b` `c`)
Pas « n'aurait pas été lisible » mais plutôt « n'est pas très lisible » Les backticks sont déjà utilisé pour des éléments d'affichage : j'ai besoin de distinguer sémantiquement quand j'écris (d'où des marquages différents) et ici quand c'est affiché (d'où le manque) ce qui est saisi et ce qui est affiché. Ce n'est pas juste d'avoir une police mono, mais d'avoir deux contextes distincts et à distinguer et qui sont tous deux en mono…
Edit : j'ai déjà eu des cas où les tables ne prenaient pas ; et aussi des syntaxe de tables différentes.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Le mieux, c'est de ne pas utiliser et imposer l'apprentissage d'une énième syntaxe mais d'utiliser les balises HTML qui sont si faciles à retenir et à utiliser et qui fonctionnent partout et avec tous les navigateurs web.
Posté par Psychofox (Mastodon) .
Évalué à 6.
Dernière modification le 20 juillet 2022 à 07:41.
Alors je comprends que ça ne parait pas évident quand un texte structuré type markdown ou asciidoc contient beaucoup de tables, mais le but de ces syntaxes est de permettre d'avoir un document à peu prés aussi lisible lorsqu'il est consulté non interprêté dans un terminal via ton pager (ou cat), un outil de diff…
Avec html t'es obligé de sortir l'artillerie lourde sinon c'est imbuvable.
J'ajouterai que si le résultat des syntaxe comme Markxxx est de rendre lisible un document, c'est en raison du faible bruit engendré par la décoration. Le "bruit" engendré par la syntaxe de décoration HTML rend la lecture d'un document au mieux difficile, au pire, à vomir.
Pour couronner le tout, la plupart des outils nécessaires au rendu HTML sont extrêmement gourmands en ressources¹. Le plus vorace est sans conteste le moteur de Chrome. On peut mieux faire.
Sinon il y a PDF mais il faut passer par une moulinette de conversion comme pandoc, par exemple. Noter que ce dernier s'applique à toute conversion, bidirectionnelle, entre formats, pas seulement Markdown ↔ HTML.
Il y a aussi la syntaxe Rich Text, poussée encore plus avant par LaTeX. Tout est question de combien de temps on veut passer sur la compréhension d'une syntaxe pour la rendre abordable à tous.
Il ne faut pas non plus perdre de vue que les développeurs, en général, n'aiment pas rédiger de la documentation. C'est juste pas leur tasse de thé café. Alors si c'est pour leur proposer des syntaxes imbitables, ça va pas arranger les choses…
Comme on peut le voir, on a le choix. Et restreindre ce choix à juste une seule syntaxe, quelle que soit l'argumentation, reviendrait à oublier les raisons pour lesquelles on a justement cet éventail de possibilités.
¹ Ouais, je sais, il y a links, très connu des utilisateurs de clic-o-dromes… Ahem… ;-)
Moi j'adore le markdown, c'est vrai que c'est limité mais il y a souvent des extensions bien répandues. Par exemple avec mkdocs et le super thème material, on peut avoir des “admonitions” qui sont top.
!!! note
Ceci est une petite note
Markdown ftw.
git is great because linus did it, mercurial is better because he didn't
# txt2tags
Posté par zurvan . Évalué à 5.
je ne peux que plussoyer : j'ai toujours détesté les limitations de Markdown. Je connais peu asciidoc, mais ça sera toujours mieux que markdown.
https://txt2tags.org/ me semblera toujours le top du top, la syntaxe semble tellement tomber sous le sens (c'est quasi la même que Creole qui a produit une documentation abondante sur les raisons de tel ou tel autre choix)…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: txt2tags
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Exactement, la raison pour laquelle je dis que la syntaxe Wiki est mieux fichue (en plus d'être plus riche de base) que Markdown ! Malheureusement, il y a beaucoup de dialectes qui ont l'avantage d'être plus riche que Creole (mais n'est-ce pas le même souci avec toutes les « saveurs » de l'autre qui font que je ne peux pas juste prendre mes écrits pour Github ou Gitlab et les mettre sur Linuxfr juste pour prendre cet exemple.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: txt2tags
Posté par patrick_g (site web personnel) . Évalué à 4.
Je plusse pour l'utilisation de txt2tags. La syntaxe est vraiment simple à utiliser.
# AsciiDoc et les tableaux
Posté par nico4nicolas . Évalué à 3.
J'aurais bien voulu faire adopter AsciiDoc(tor) à mes collègues car je le trouve très avantageux pour faire bien des choses mais un élément rédhibitoire à une adoption générale est la création de tableaux. C'est une caractéristique qui me semble commune à tous ces langages de documentation en "plain text" mais la différence se fait avec un éditeur WYSIWYG.
[^] # Re: AsciiDoc et les tableaux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 19 juillet 2022 à 19:29.
Que reproches-tu à ses tableaux (que je trouve quand même plus avancés que Markdown) ?
https://docs.asciidoctor.org/asciidoc/latest/tables/build-a-basic-table/
https://blog.mrhaki.com/2014/11/awesome-asciidoctor-changing-grid-and.html
(c'est son principe qu'à repris la syntaxe MediaWiki et on voit que tous les cas courants de tableaux sont présents dans Wikipédia.) Quel cas manque-t-il à ton usage ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: AsciiDoc et les tableaux
Posté par Leirda . Évalué à 2.
Personnellement, j’ai un peu de mal avec la syntaxe des tableaux d’Asciidoc(tor) pour avoir pas mal joué avec.
Je trouve que les différentes caractères à utiliser pour configurer les trucs comme l’alignement, la taille des colonnes, etc. ne sont pas intuitif à l’utilisation (un seul caractère n’est pas suffisamment descriptif, l’ordre des caractères change tout d’une manière relativement arbitraire de prime abord, c’est pas facile de comprendre ce que ça veut dire si on revient dessus plus tard, etc).
C’est en fait mon plus gros reproche à Asciidoc que je trouve sinon excellent, mais cette syntaxe est déjà plus permissive et plus simple que celles du Markdown de toute manière.
Je suis fan du combo Emacs + OrgMode pour ce qui est des tableaux. J’ai été bluffé par la simplicité de création et d’édition des tableaux dans Emacs qui sont en plus très simple avec la syntaxe d’OrgMode.
En fait, OrgMode c’est même vraiment excellent, et j’ai tendance à favoriser ce format pour tout ce qui ne justifie pas carrément l’utilisation de LaTeX.
[^] # Re: AsciiDoc et les tableaux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je crois comprendre… Mais ces tableaux sont encore lpus basiques non ?
https://orgmode.org/guide/Tables.html
…c'est comparabel aux tableaux du Markdown de Linuxfr ou GMF
…et si on a moins de fonctionnalité, c'est forcément plus simple. :-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: AsciiDoc et les tableaux
Posté par nico4nicolas . Évalué à 3.
Le reproche n'est pas lié à AsciiDoc spécifiquement mais aux formats de documents textuels (dont Markdown et Latex) pour lesquels les tableaux ne sont pas faciles à construire puis, lorsque le tableau est un peu volumineux, pas facile à relire. C'est, à mon avis, le point de réticence que peuvent avoir des utilisateurs qui sont habitués à du WYSIWYG.
[^] # Re: AsciiDoc et les tableaux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ah d'accord, je comprends mieux. (Vous devez avoir beaucoup de gros tableaux…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: AsciiDoc et les tableaux
Posté par Solareagle . Évalué à 1.
Avec LaTeX, il existe plusieurs solutions pour gérer les tableaux, avec en particulier l'import du contenu à partir d'un fichier externe.
De plus, il suffit d'enregistrer les modèles choisis sous forme de snippets de code dans son éditeur préféré pour gagner du temps à la création de nouveaux tableaux.
Et c'est sans compter avec les possibilités de mise en page très étendues grâce aux extensions, par exemple des lignes de couleurs de fond alternées ou d'alignement des nombres que la virgule (avec SIunitx). Tout le contraire de Markdown, quoi.
Par contre, ce dernier est très pratique pour réaliser une mise en forme basique, et avec un css adéquat, on peut obtenir un résultat visuellement joli, et on peut même ajouter des maths avec Mathjax, mais pour les tableaux, c'est quasiment le désert.
[^] # Re: AsciiDoc et les tableaux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Oui :-) Mais sa remarque initiale n'était pas sur la possibilité comme je l'avais cru aussi, mais sur la lisibilité et le bruit d'écriture avec les formatages textes : «
» Pour que ton tableau soit lisible, il faut bien aligner le délimiteur de champs (
&en LaTeX) et que les lignes ne débordent pas… et qu'il n'y ait pas pas besoin de formatage avancé (fusion de lignes ou de colonnes, justification spécifiques et changeantes, etc.) qui vont automatiquement ajouter du bruit dans le source. Pour le rendu, pas de souci : LaTeX et AsciiDoc permettent de faire de très belles choses avancées en y passant peu de temps (quand on maîtrise assez pour ne pas se perdre dans le marquage.)Attention, le support des maths est comme pour les tableaux dépendant des dialectes Markdown utilisés. Tous n'utilisent pas Mathjax et pour ceux qui le font n'ont pas les mêmes options (par exemple![` vs `[[…]]` vs](data:image/svg+xml;base64,PHN2ZyB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGlu%0AayIgdmlld0JveD0iMCAtNzA1LjI3NzQ4OTAwMjU0MSA1MDU3IDg5MC41NTQ5%0ANzgwMDUwODE4IiBzdHlsZT0id2lkdGg6IDExLjY4N2V4OyBoZWlnaHQ6IDIu%0AMDQ4ZXg7IHZlcnRpY2FsLWFsaWduOiAtMC40ODJleDsgbWFyZ2luOiAxcHgg%0AMHB4OyBwb3NpdGlvbjogc3RhdGljOyIgeG1sbnM9Imh0dHA6Ly93d3cudzMu%0Ab3JnLzIwMDAvc3ZnIj48ZGVmcyBpZD0iTWF0aEpheF9TVkdfZ2x5cGhzIj48%0AcGF0aCBpZD0iU1RJWFdFQk1BSU4tMjAxOCIgc3Ryb2tlLXdpZHRoPSIxMCIg%0AZD0iTTIyNyA2NzZsOSAtMTljLTU1IC0zOCAtODIgLTczIC04MiAtMTA2YzAg%0ALTggNiAtMTQgMTQgLTE0YzAgMCAyIDAgNyAyYzYgMSAxMyAyIDIwIDJjMzcg%0AMCA1OSAtMTkgNTkgLTUxYzAgLTM0IC0yNCAtNTcgLTU5IC01N2MtNDYgMCAt%0AODAgMzggLTgwIDg5YzAgNjAgNDUgMTIxIDExMiAxNTRaIj48L3BhdGg+PHBh%0AdGggaWQ9IlNUSVhXRUJNQUlOSS03NiIgc3Ryb2tlLXdpZHRoPSIxMCIgZD0i%0ATTIwNyA3MGwzMSAzMmM3MiA3NCAxMzcgMTg0IDEzNyAyMzFjMCAxMCAtNSAx%0ANyAtMTggMjljLTE4IDE2IC0yNSAyOSAtMjUgNDVjMCAyMSAxNyAzNCAzOCAz%0ANGMzMyAwIDU2IC0zMiA1NiAtNTljMCAtNDMgLTI4IC0xMDEgLTYzIC0xNTVj%0ALTQ1IC03MCAtMTAxIC0xMzQgLTExOSAtMTUzYy01NSAtNTkgLTgyIC05MiAt%0AOTkgLTkyYy02IDAgLTkgMTAgLTkgMjd2MjRjMCA2OSAtMTEgMjAyIC0yNCAy%0ANzhzLTI0IDkzIC02MSA5MyBjLTEwIDAgLTIwIDAgLTMxIC0xdjEzYzQ1IDcg%0AODAgMTQgMTEyIDIxYzggMyAxNSA0IDIwIDRjOSAwIDkgLTYgMzAgLTExNGMx%0AMyAtNjcgMTkgLTEyMiAyNSAtMjU3WiI+PC9wYXRoPjxwYXRoIGlkPSJTVElY%0AV0VCTUFJTkktNzMiIHN0cm9rZS13aWR0aD0iMTAiIGQ9Ik0zNjYgNDQybC0y%0AMCAtMTQwaC0xNmMtMTAgODMgLTQwIDExNiAtODkgMTE2Yy0zNSAwIC01OSAt%0AMjAgLTU5IC01N2MwIC0yNyAxNSAtNTYgNTQgLTEwMmM1MCAtNTggNjggLTk3%0AIDY4IC0xMzZjMCAtODMgLTYxIC0xMzQgLTE0NCAtMTM0Yy0xNyAwIC0zMiAx%0AIC01NSAxMGMtMTkgOCAtMzMgOSAtNDQgOXMtMjIgLTUgLTI5IC0yMWgtMTZs%0AMjAgMTU5aDE2YzE0IC05NSA0OCAtMTM2IDEwMCAtMTM2YzQ3IDAgNzYgMjgg%0ANzYgNzcgYzAgMzIgLTE3IDY2IC01NiAxMTVjLTQzIDU0IC02MyA5OSAtNjMg%0AMTMxYzAgNjYgNDcgMTA4IDEyMSAxMDhjMTcgMCAzMSAtMyA1NiAtMTBjMTkg%0ALTYgMjggLTcgMzYgLTdjMTUgMCAyMiA0IDMwIDE4aDE0WiI+PC9wYXRoPjxw%0AYXRoIGlkPSJTVElYV0VCTUFJTi0yMDE4IiBzdHJva2Utd2lkdGg9IjEwIiBk%0APSJNMjI3IDY3Nmw5IC0xOWMtNTUgLTM4IC04MiAtNzMgLTgyIC0xMDZjMCAt%0AOCA2IC0xNCAxNCAtMTRjMCAwIDIgMCA3IDJjNiAxIDEzIDIgMjAgMmMzNyAw%0AIDU5IC0xOSA1OSAtNTFjMCAtMzQgLTI0IC01NyAtNTkgLTU3Yy00NiAwIC04%0AMCAzOCAtODAgODljMCA2MCA0NSAxMjEgMTEyIDE1NFoiPjwvcGF0aD48cGF0%0AaCBpZD0iU1RJWFdFQk1BSU4tNUIiIHN0cm9rZS13aWR0aD0iMTAiIGQ9Ik0y%0AOTkgLTE1NmgtMjExdjgxOGgyMTF2LTI1aC04M2MtMzQgMCAtNTIgLTEyIC01%0AMiAtNDh2LTY2NmMwIC00MCAxOSAtNTQgNTIgLTU0aDgzdi0yNVoiPjwvcGF0%0AaD48cGF0aCBpZD0iU1RJWFdFQk1BSU4tNUIiIHN0cm9rZS13aWR0aD0iMTAi%0AIGQ9Ik0yOTkgLTE1NmgtMjExdjgxOGgyMTF2LTI1aC04M2MtMzQgMCAtNTIg%0ALTEyIC01MiAtNDh2LTY2NmMwIC00MCAxOSAtNTQgNTIgLTU0aDgzdi0yNVoi%0APjwvcGF0aD48cGF0aCBpZD0iU1RJWFdFQk1BSU4tMjAyNiIgc3Ryb2tlLXdp%0AZHRoPSIxMCIgZD0iTTg4OCA0M2MwIC0yOSAtMjYgLTU0IC01NiAtNTRjLTMx%0AIDAgLTU1IDI0IC01NSA1NXMyNSA1NiA1NiA1NmMyOSAwIDU1IC0yNyA1NSAt%0ANTd6TTU1NSA0M2MwIC0yOSAtMjYgLTU0IC01NiAtNTRjLTMxIDAgLTU1IDI0%0AIC01NSA1NXMyNSA1NiA1NiA1NmMyOSAwIDU1IC0yNyA1NSAtNTd6TTIyMiA0%0AM2MwIC0yOSAtMjYgLTU0IC01NiAtNTRjLTMxIDAgLTU1IDI0IC01NSA1NXMy%0ANSA1NiA1NiA1NmMyOSAwIDU1IC0yNyA1NSAtNTdaIj48L3BhdGg+PHBhdGgg%0AaWQ9IlNUSVhXRUJNQUlOLTVEIiBzdHJva2Utd2lkdGg9IjEwIiBkPSJNMjQ1%0AIC0xNTZoLTIxMXYyNWg4OGMzNSAwIDQ3IDE1IDQ3IDQ2djY2OGMwIDM1IC0x%0AMyA1NCAtNTEgNTRoLTg0djI1aDIxMXYtODE4WiI+PC9wYXRoPjxwYXRoIGlk%0APSJTVElYV0VCTUFJTi01RCIgc3Ryb2tlLXdpZHRoPSIxMCIgZD0iTTI0NSAt%0AMTU2aC0yMTF2MjVoODhjMzUgMCA0NyAxNSA0NyA0NnY2NjhjMCAzNSAtMTMg%0ANTQgLTUxIDU0aC04NHYyNWgyMTF2LTgxOFoiPjwvcGF0aD48cGF0aCBpZD0i%0AU1RJWFdFQk1BSU4tMjAxOCIgc3Ryb2tlLXdpZHRoPSIxMCIgZD0iTTIyNyA2%0ANzZsOSAtMTljLTU1IC0zOCAtODIgLTczIC04MiAtMTA2YzAgLTggNiAtMTQg%0AMTQgLTE0YzAgMCAyIDAgNyAyYzYgMSAxMyAyIDIwIDJjMzcgMCA1OSAtMTkg%0ANTkgLTUxYzAgLTM0IC0yNCAtNTcgLTU5IC01N2MtNDYgMCAtODAgMzggLTgw%0AIDg5YzAgNjAgNDUgMTIxIDExMiAxNTRaIj48L3BhdGg+PHBhdGggaWQ9IlNU%0ASVhXRUJNQUlOSS03NiIgc3Ryb2tlLXdpZHRoPSIxMCIgZD0iTTIwNyA3MGwz%0AMSAzMmM3MiA3NCAxMzcgMTg0IDEzNyAyMzFjMCAxMCAtNSAxNyAtMTggMjlj%0ALTE4IDE2IC0yNSAyOSAtMjUgNDVjMCAyMSAxNyAzNCAzOCAzNGMzMyAwIDU2%0AIC0zMiA1NiAtNTljMCAtNDMgLTI4IC0xMDEgLTYzIC0xNTVjLTQ1IC03MCAt%0AMTAxIC0xMzQgLTExOSAtMTUzYy01NSAtNTkgLTgyIC05MiAtOTkgLTkyYy02%0AIDAgLTkgMTAgLTkgMjd2MjRjMCA2OSAtMTEgMjAyIC0yNCAyNzhzLTI0IDkz%0AIC02MSA5MyBjLTEwIDAgLTIwIDAgLTMxIC0xdjEzYzQ1IDcgODAgMTQgMTEy%0AIDIxYzggMyAxNSA0IDIwIDRjOSAwIDkgLTYgMzAgLTExNGMxMyAtNjcgMTkg%0ALTEyMiAyNSAtMjU3WiI+PC9wYXRoPjxwYXRoIGlkPSJTVElYV0VCTUFJTkkt%0ANzMiIHN0cm9rZS13aWR0aD0iMTAiIGQ9Ik0zNjYgNDQybC0yMCAtMTQwaC0x%0ANmMtMTAgODMgLTQwIDExNiAtODkgMTE2Yy0zNSAwIC01OSAtMjAgLTU5IC01%0AN2MwIC0yNyAxNSAtNTYgNTQgLTEwMmM1MCAtNTggNjggLTk3IDY4IC0xMzZj%0AMCAtODMgLTYxIC0xMzQgLTE0NCAtMTM0Yy0xNyAwIC0zMiAxIC01NSAxMGMt%0AMTkgOCAtMzMgOSAtNDQgOXMtMjIgLTUgLTI5IC0yMWgtMTZsMjAgMTU5aDE2%0AYzE0IC05NSA0OCAtMTM2IDEwMCAtMTM2YzQ3IDAgNzYgMjggNzYgNzcgYzAg%0AMzIgLTE3IDY2IC01NiAxMTVjLTQzIDU0IC02MyA5OSAtNjMgMTMxYzAgNjYg%0ANDcgMTA4IDEyMSAxMDhjMTcgMCAzMSAtMyA1NiAtMTBjMTkgLTYgMjggLTcg%0AMzYgLTdjMTUgMCAyMiA0IDMwIDE4aDE0WiI+PC9wYXRoPjwvZGVmcz48ZyBz%0AdHJva2U9ImJsYWNrIiBmaWxsPSJibGFjayIgc3Ryb2tlLXdpZHRoPSIwIiB0%0AcmFuc2Zvcm09Im1hdHJpeCgxIDAgMCAtMSAwIDApIj48dXNlIHhsaW5rOmhy%0AZWY9IiNTVElYV0VCTUFJTi0yMDE4Ij48L3VzZT48dXNlIHhsaW5rOmhyZWY9%0AIiNTVElYV0VCTUFJTkktNzYiIHg9IjMzOCIgeT0iMCI+PC91c2U+PHVzZSB4%0AbGluazpocmVmPSIjU1RJWFdFQk1BSU5JLTczIiB4PSI3ODciIHk9IjAiPjwv%0AdXNlPjx1c2UgeGxpbms6aHJlZj0iI1NUSVhXRUJNQUlOLTIwMTgiIHg9IjEx%0AODEiIHk9IjAiPjwvdXNlPjx1c2UgeGxpbms6aHJlZj0iI1NUSVhXRUJNQUlO%0ALTVCIiB4PSIxNTE5IiB5PSIwIj48L3VzZT48dXNlIHhsaW5rOmhyZWY9IiNT%0AVElYV0VCTUFJTi01QiIgeD0iMTg1NyIgeT0iMCI+PC91c2U+PHVzZSB4bGlu%0AazpocmVmPSIjU1RJWFdFQk1BSU4tMjAyNiIgeD0iMjE5NSIgeT0iMCI+PC91%0Ac2U+PHVzZSB4bGluazpocmVmPSIjU1RJWFdFQk1BSU4tNUQiIHg9IjMyMDAi%0AIHk9IjAiPjwvdXNlPjx1c2UgeGxpbms6aHJlZj0iI1NUSVhXRUJNQUlOLTVE%0AIiB4PSIzNTM4IiB5PSIwIj48L3VzZT48dXNlIHhsaW5rOmhyZWY9IiNTVElY%0AV0VCTUFJTi0yMDE4IiB4PSIzODc2IiB5PSIwIj48L3VzZT48dXNlIHhsaW5r%0AOmhyZWY9IiNTVElYV0VCTUFJTkktNzYiIHg9IjQyMTQiIHk9IjAiPjwvdXNl%0APjx1c2UgeGxpbms6aHJlZj0iI1NUSVhXRUJNQUlOSS03MyIgeD0iNDY2MyIg%0AeT0iMCI+PC91c2U+PC9nPjwvc3ZnPg==%0A)
(…)$` etc. mais aussi le support des équations chimiques qu'on n'a pas sur Linuxfr par exemple.)
${mathjax} …“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: AsciiDoc et les tableaux
Posté par BFG . Évalué à 6.
Markdown ne possède pas de tableaux du tout (à part en insérant du HTML brut). CommonMark ne corrige pas ce problème non plus. Ce sont quelques implémentations éparses qui proposent des tableaux, avec des syntaxes subtilement différentes.
Ça catalyse parfaitement tout ce pourquoi Markdown est très mauvais :
- trop simpliste, ne permet même pas des choses courantes comme des tableaux
- pas assez normé, fragmentation extrême, les implémentations sont incompatibles les unes avec les autres, CommonMark est là pour aider, mais uniquement sur la syntaxe de base qui est elle même mal normée
Un exemple de liste qui ne produit pas le même résultat partout :
foo:
- bar
Voir babelmark pour les résultats
Même CommonMark est instable et change trop d'une version à l'autre, cf une différence non-négligeable entre 0.28 et 0.29.
En soi, on peut dire qu'un « document markdown » est en fait très lié à une seule implémentation de rendu, celle choisie par celui ou celle qui a édité le document. En soi, markdown désigne bien trop de choses différentes. On devrait plutôt parler par exemple de « document Gitlab Markdown » ou « document CommonMark 0.30 », et ensuite veiller à ne pas tenter de le faire rendre sur une autre implémentation, sous peine d'avoir un rendu très mauvais.
# Oui mais...
Posté par Dring . Évalué à 7.
Asciidoc est certes plus puissant, mais Ô combien moins accessible au non initié.
Rédiger de la doc, c'est déjà difficile de convaincre les gens, et d'arriver à leur faire faire. Si en plus ils doivent se poser des questions existentielles, c'est pas la peine de rêver. Le critère pour espérer avoir de la doc, c'est rendre ça le plus simple possible, tant pis si c'est au détriment des fonctionnalités.
Par contre, j'avoue que le manque de normalisation est un peu pénible. Quand on met du markdown dans une spec API (type OAS ou Swagger), c'est très chiant de jamais savoir comment ça sera rendu au final (sachant que chaque portail API peut interpréter ça légèrement différemment).
[^] # Re: Oui mais...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0.
J'ai pourtant l'impression qu'on se pose beaucoup beaucoup de questions existentielles avec Markdown non ? Ou je suis un cas isolé ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Oui mais...
Posté par raphj . Évalué à 3. Dernière modification le 20 juillet 2022 à 09:06.
L’avantage c’est que Markdown c’est tellement pauvre pour écrire de la doc qu’il n’y a pas beaucoup de questions à se poser justement ! (/s)
Plus sérieusement, je préfère avoir une syntaxe un peu plus compliquée et ne pas tomber sur des limitations en pleine rédaction de doc. Moi c’est plus ça qui peut me faire sortir du « flow ». De toute façon, on finit par connaitre les éléments de syntaxe après un peu de pratique, mais la limitation, elle, ne s’en va pas. Et je préfère devoir chercher un peu comment faire quelque chose (j’ai l’habitude, j’ai pratiqué LaTeX…) que me rendre compte que ce n’est pas possible et devoir compromettre. Parfois, compromettre donne un meilleur résultat, mais parfois, c’est juste casse-pieds.
Et Markdown, tu finis par devoir connaitre les petites subtilités et limites de chaque implémentation, donc ce n’est pas si simple.
[^] # Re: Oui mais...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 20 juillet 2022 à 11:53.
On est d'accord :-) C'est juste que j'avais à l'esprit que quand la syntaxe est simple, on a moins d'interrogations et au début j'en avait quand même pas mal avec Markdown (comparé aux syntaxes Wiki et Asciidoc.) Plus tard, j'ai continué à me poser des questions parce-que pendant longtemps je n'ai pas compris que c'était juste limité et qu'il fallait pas chercher (sinon on perd des heures pour découvrir que ce n'est pas possible) et faire des compromissions un peu étranges et peu satisfaisantes. Encore beaucoup de questions quand on se préoccupe de la portabilité : si je n'écris que pour Linuxfr, pas de soucis ; si j'espère réutiliser le même sur Medium ou dans mon Gitea ou autre, ça va être la prise de tête pas drôle.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Oui mais...
Posté par raphj . Évalué à 2.
Oui, effectivement, on est d'accord, on dit la même chose :-)
j'étais un peu sarcastique et taquin.
Je me suis déjà pris la tête de cette manière avec Markdown.
(Avec LaTeX aussi, je me suis pris la tête, mais pas de la même manière)
# adoption
Posté par Psychofox (Mastodon) . Évalué à 3.
Au final quelque soit la foece de asciidoc comparé à markdown en terme se fonctionnalités, ça ne vaut rien une fois qu'on prend en compte l'adoption bien meilleure de ce dernier dans une foultitude d'outils.
[^] # Re: adoption
Posté par Leirda . Évalué à 3.
Je suis d’accord, mais je tiens à noter que la plupart des forges de code supportent nativement Asciidoc, autant que le Markdown.
Ça ne présente donc quasiment aucun inconvénient de l’utiliser dans un dépôt hébergé sur des plateformes comme Github, Gitlab, Codeberg (ou n’importe quelle instance Gitea)…
Pour ce qui est du reste, les outils utilisant le Markdown (l’éditeur de LinuxFR!, discourse et autres) pour des trucs relativement basiques sont plutôt compatible avec Asciidoc (enfin… l’inverse!) qui fait de gros efforts pour ressembler à Markdown sur les trucs de base (équivalence entre les
=et les#pour indiquer les niveaux de titre, gestion du markup de base similaire, etc).J’ai l’impression que les subtilités entre Markdown et Asciidoc deviennent importantes sur des éléments plus complexes (images, blocs de code, tableaux) ou sur des cas où Markdown peut être ambigü (imbrications de styles).
Du coup, il me semble qu’apprendre le Asciidoc permet plus ou moins de se servir du Markdown quand même ! :-)
[^] # Re: adoption
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Pas vérifié pour les autres, mais Github supporte aussi ReStruturedText : comparé à Asciidoc c'est tout aussi puissant mais moins compatible Markdown.
Concernant les outils disponibles, le lien mentionne justement le fort couplage entre un site/plateforme et une appli, le format n'est pas portable/pérenne pour de la doc. Les reproches faits à Markdown peuvent se résumer dans l'absence de marquage/structuration évolué/complexe et beaucoup d’ambiguïté pour des choses quand même simples.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: adoption
Posté par Psychofox (Mastodon) . Évalué à 2.
Mais est-ce vraiment pertinent. De ce que j'ai lu de l'article la plupart des exemplea de fonctionnalités mentionnés font plus partie de la catégorie "bon à avoir" que "indispensable".
J'ai rarement besoin d'utiliser des balises html parce que je me sens limité avec markdown. Je crois que la seule que j'utilise un peu régulièremnt est la balise dans une cellule de tableau pour avoir des rwtours à la ligne dans une cellule.
Et je trouve que les grosses limitations de markdown m'imposent de faire du contenu sobre ce qui n'est au final pas plus mal.
[^] # Re: adoption
Posté par Psychofox (Mastodon) . Évalué à 4.
Ah et la seule chose qui m'a retenu l'attention dans les exemples de l'article, c'est l'inclusion s'un bout de code via une directive include. De prime abord tu te dis "cool" plus besoin de faire des copier/coller…puis tu réfléchis un peu et tu te dis que si tu fais ça ton markdown ne peut plus bouger ou tu vas péter le lien, tu pourrais avoir des incohérences entre ce que dit la doc et l'exemple dans le code block parce que tu as modifié le code, etc, etc. Et cela sans que tu ne t'en rendes compte si tu ne vas pas vérifier. Et au final ce sont ces vérifications et changements qui te coûtent plus qu'un pauvre petit copier/coller dans le cycle de vie de ta documentation.
Du coup y gagnes t'on vraiment?
[^] # Re: adoption
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 20 juillet 2022 à 08:19.
Assez récemment encore j'en ai eu besoin, de mettre du balisage HTML dans le dernier journal que j'ai pondu ici. :-) Rien que d'utiliser des tableaux montre déjà que tu es confronté aux grosses limitations de Markdown car ce n'est pas de base (tu utilises un ajout qui n'est garanti de fonctionner dans tous les dialectes et donc n'est pas portable.) ;-) Ce que tu appelles contenu sobre, pour moi ce sont surtout des commentaires (comme j'ai dit dans un autre commentaire)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: adoption
Posté par Psychofox (Mastodon) . Évalué à 4.
Mouais les tables sont supportées par toutes les implémentations que j'ai pu utiliser donc c'est devenu un standard de fait.
Pour les balises dans ton journal, tu parles des balises ? Je n'ai pas bien saisi pourquoi tu les as utilisé en fait et en quoi ton journal n'aurait pas été lisible et sémantiquement correct sans elles. Et en général si je veux une police mono dans un bout de markdown sans être dans un bloc se code j'utilise les
backticks(`backticks`) et si je veux représenter des touches uniques je le fait comme celaabc( `a` `b` `c`)[^] # Re: adoption
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 20 juillet 2022 à 11:43.
Pas « n'aurait pas été lisible » mais plutôt « n'est pas très lisible » Les backticks sont déjà utilisé pour des éléments d'affichage : j'ai besoin de distinguer sémantiquement quand j'écris (d'où des marquages différents) et ici quand c'est affiché (d'où le manque) ce qui est saisi et ce qui est affiché. Ce n'est pas juste d'avoir une police mono, mais d'avoir deux contextes distincts et à distinguer et qui sont tous deux en mono…
Edit : j'ai déjà eu des cas où les tables ne prenaient pas ; et aussi des syntaxe de tables différentes.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# HTML
Posté par tout . Évalué à 5.
Le mieux, c'est de ne pas utiliser et imposer l'apprentissage d'une énième syntaxe mais d'utiliser les balises HTML qui sont si faciles à retenir et à utiliser et qui fonctionnent partout et avec tous les navigateurs web.
[^] # Re: HTML
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 20 juillet 2022 à 07:41.
Alors je comprends que ça ne parait pas évident quand un texte structuré type markdown ou asciidoc contient beaucoup de tables, mais le but de ces syntaxes est de permettre d'avoir un document à peu prés aussi lisible lorsqu'il est consulté non interprêté dans un terminal via ton pager (ou cat), un outil de diff…
Avec html t'es obligé de sortir l'artillerie lourde sinon c'est imbuvable.
[^] # Re: HTML
Posté par FantastIX . Évalué à 4.
J'ajouterai que si le résultat des syntaxe comme Markxxx est de rendre lisible un document, c'est en raison du faible bruit engendré par la décoration. Le "bruit" engendré par la syntaxe de décoration HTML rend la lecture d'un document au mieux difficile, au pire, à vomir.
Pour couronner le tout, la plupart des outils nécessaires au rendu HTML sont extrêmement gourmands en ressources¹. Le plus vorace est sans conteste le moteur de Chrome. On peut mieux faire.
Sinon il y a PDF mais il faut passer par une moulinette de conversion comme pandoc, par exemple. Noter que ce dernier s'applique à toute conversion, bidirectionnelle, entre formats, pas seulement
Markdown ↔ HTML.Il y a aussi la syntaxe Rich Text, poussée encore plus avant par LaTeX. Tout est question de combien de temps on veut passer sur la compréhension d'une syntaxe pour la rendre abordable à tous.
Il ne faut pas non plus perdre de vue que les développeurs, en général, n'aiment pas rédiger de la documentation. C'est juste pas leur tasse de
thécafé. Alors si c'est pour leur proposer des syntaxes imbitables, ça va pas arranger les choses…Comme on peut le voir, on a le choix. Et restreindre ce choix à juste une seule syntaxe, quelle que soit l'argumentation, reviendrait à oublier les raisons pour lesquelles on a justement cet éventail de possibilités.
¹ Ouais, je sais, il y a links, très connu des utilisateurs de clic-o-dromes… Ahem… ;-)
[^] # Re: HTML
Posté par flan (site web personnel) . Évalué à 1.
Pourquoi les retenir ?
Un des avantages est quand même de pouvoir utiliser du WISYWIG assez facilement.
# mkdocs pour ma part
Posté par David Demelier (site web personnel) . Évalué à 4.
Moi j'adore le markdown, c'est vrai que c'est limité mais il y a souvent des extensions bien répandues. Par exemple avec mkdocs et le super thème material, on peut avoir des “admonitions” qui sont top.
Markdown ftw.
git is great because linus did it, mercurial is better because he didn't
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.