Le problème, c'est que tu ne peux jamais connaître tes besoins a priori.
Par exemple, j'ai pendant des années développé ma propre syntaxe de style markdown, avec laquelle j'ai rédigé l'ensemble de mes documents (pages de manuels et notes, pages HTML, et même des recettes de cuisine). J'avais fait les choses bien, comme séparer sous forme le modules Perl l'analyseur du source d'avec les traducteurs vers les différentes sorties, et prévoir un mécanisme d'échappement qui permettait de traiter certains blocs comme on le voulait depuis le script de l'utilisateur (pas seulement avec des regex, mais avec toute la syntaxe Perl, donc).
Quand j'ai amorcé le projet, je me suis dit que je n'aurai jamais besoin de gérer les notes en bas de page, car je ne fais pas de travaux universitaires et c'est un procédé que je n'aime pas beaucoup. La suite m'a démontré que j'avais raison, car jamais les documents que j'ai rédigés n'ont appelé pareilles notes. Seulement voilà, un jour j'ai eu l'idée d'« éditer » un texte tiers qui lui en comprenait, et là ça a été tellement la galère intégrale pour intégrer la chose proprement (il fallait que les notes puissent utiliser l'ensemble de la syntaxe, pas seulement des paragraphes) que ça m'a dégoûté (bon, sans doute aussi avais-je un peu perdu le feu sacré, mais ça n'aurait pas été mieux si j'avais eu à gérer un tas hétéroclite de regex ad hoc).
C'est là que je me suis souvenu que lors de mes débuts sur le oueb, on écrivait encore le HTML à la main et que tout novice que j'étais ça ne m'avait jamais semblé insurmontable, peut-être un peu moins confortable que la syntaxe wiki qui a émergé après, mais pas fondamentalement différent (le wiki ne m'a jamais paru révolutionnaire d'un point de vue strictement syntaxique). J'ai alors réalisé que si je l'avais adopté en tant que format source au lieu de me laisser appâter par la facilité relative de la syntaxe wiki (qui est au fond une formalisation étendue de la syntaxe courante du courriel) j'aurais eu quelque chose de pas plus difficile à analyser (le XHTML 1.0 n'est jamais qu'une pile de balises dont l'empilement est cadré par de doctype) tout en étant nettement plus souple, complet, éprouvé, et surtout directement utilisable. Car après tout, le HTML est un format voire le format de sortie pour toute syntaxe de type markdown (les autres sont souvent conçus comme des formats d'archivage secondaires), d'où il n'est pas idiot de conclure que tout ce que peuvent ces syntaxes est nécessairement représentable en HTML.
[^] # Re: table
Posté par Ignatz Ledebur . En réponse à la dépêche CommonMark, une syntaxe Markdown en commun et répandue. Évalué à 6.
Le problème, c'est que tu ne peux jamais connaître tes besoins a priori.
Par exemple, j'ai pendant des années développé ma propre syntaxe de style markdown, avec laquelle j'ai rédigé l'ensemble de mes documents (pages de manuels et notes, pages HTML, et même des recettes de cuisine). J'avais fait les choses bien, comme séparer sous forme le modules Perl l'analyseur du source d'avec les traducteurs vers les différentes sorties, et prévoir un mécanisme d'échappement qui permettait de traiter certains blocs comme on le voulait depuis le script de l'utilisateur (pas seulement avec des regex, mais avec toute la syntaxe Perl, donc).
Quand j'ai amorcé le projet, je me suis dit que je n'aurai jamais besoin de gérer les notes en bas de page, car je ne fais pas de travaux universitaires et c'est un procédé que je n'aime pas beaucoup. La suite m'a démontré que j'avais raison, car jamais les documents que j'ai rédigés n'ont appelé pareilles notes. Seulement voilà, un jour j'ai eu l'idée d'« éditer » un texte tiers qui lui en comprenait, et là ça a été tellement la galère intégrale pour intégrer la chose proprement (il fallait que les notes puissent utiliser l'ensemble de la syntaxe, pas seulement des paragraphes) que ça m'a dégoûté (bon, sans doute aussi avais-je un peu perdu le feu sacré, mais ça n'aurait pas été mieux si j'avais eu à gérer un tas hétéroclite de regex ad hoc).
C'est là que je me suis souvenu que lors de mes débuts sur le oueb, on écrivait encore le HTML à la main et que tout novice que j'étais ça ne m'avait jamais semblé insurmontable, peut-être un peu moins confortable que la syntaxe wiki qui a émergé après, mais pas fondamentalement différent (le wiki ne m'a jamais paru révolutionnaire d'un point de vue strictement syntaxique). J'ai alors réalisé que si je l'avais adopté en tant que format source au lieu de me laisser appâter par la facilité relative de la syntaxe wiki (qui est au fond une formalisation étendue de la syntaxe courante du courriel) j'aurais eu quelque chose de pas plus difficile à analyser (le XHTML 1.0 n'est jamais qu'une pile de balises dont l'empilement est cadré par de doctype) tout en étant nettement plus souple, complet, éprouvé, et surtout directement utilisable. Car après tout, le HTML est un format voire le format de sortie pour toute syntaxe de type markdown (les autres sont souvent conçus comme des formats d'archivage secondaires), d'où il n'est pas idiot de conclure que tout ce que peuvent ces syntaxes est nécessairement représentable en HTML.