Comme déjà dit dans 12 fils différents, ça ne me semble assez évident sans argumenter outre mesure que Markdown est LE format de syntaxe légère « standard de fait », le plus utilisé au monde dans des tonnes de logiciels différents, et donc avec de très nombreuses bibliothèques déjà utilisables, en JS en PHP et autre, à la fois pour compiler et générer le HTML final, mais aussi pour avoir des éditeurs déjà prêt à l’emploi etc. On ne va pas encore s’enfermer dans un format utilisé de manière confidentiel, c’est déjà ce qu’on fait depuis 20 ans.
Cela n’empêche personne de faire un plugin « AsciiDoc » qui remplace tout si on préfère (c’est bien ce que fait le plugin Markdown actuel qui remplace la syntaxe SPIP).
Pour le futur « par défaut », il me semble qu’on va à peu près tous dans la direction de Markdown, histoire à la fois de réutiliser de l’existant facilement mais aussi de capitaliser sur ce que les utilisateurices connaissent déjà, ce qui leur facilite la compréhension et l’utilisation (la proba de déjà connaitre au moins les bases de MD est énormément supérieure à connaitre DocBook ou SPIP).
Et ensuite il y aura évidemment un plugin legacy syntaxe SPIP pour celleux qui n’ont pas le temps ou flemme de convertir un ancien site, pour que ça puise reste tel quel sans refonte. Mais aussi des outils pour celleux qui veulent ! Donc tout le monde il est content.
Les utilisateurices qui ne connaîtraient pas encore SPIP, nuance.
C’est un peu méprisant. Il y a aussi des gens qui ont été formé·es à utiliser la syntaxe SPIP, et qui n’auront pas forcément envie d’apprendre une nouvelle syntaxe.
Certes il y aurait un éditeur wysiwym, mais c’est un changement radical.
Bé oui ça rentre dans le « pas le temps/pas les moyens » (en temps, en finance, en RH) pour prévoir une migration d’une syntaxe à une autre. C’est assez factuel, de toutes tailles (parce que petite asso et pas les moyens de le faire, ou inversement parce que très gros et pas les moyens de migrer + former des tonnes de gens) il y aura des propriétaires de sites qui ne pourront/voudront faire cette migration. Je ne vois pas ce qu’il y a de méprisant à ça… Et pour elleux il y aura toujours un plugin legacy pour garder l’ancienne syntaxe (et l’ancien éditeur basique qui va forcément avec).
Wouldn’t it be as easy as [(#TEXTE**|markdown|typo)] to support Markdown and TextWheel at the same time?
Or are there any incompatibilities between TextWheel and Markdown?
If the user doesn’t add any markdown then |markdown filter will do nothing. If user will use TextWheel syntax, |typo (if I’m not wrong) will take care of that.
I think line-breaks need to be handled properly, TextWheel I believe handles them differently than MD.
If it’s possible like that, then the user will not have to chose between TextWheel or MD. They will chose between the legacy editor for TextWheel editor if they prefer that, or the MD editor that supports WYSIWYG for the markdown syntax. The TextWheel syntax remains non-WYSIWYG.
→ Great, I think it’s important that users can add html whenever MD or TW does not suffice.
Oui et ça fonctionne plutôt bien, mais on ne peut pas copier-coller le texte directement de LibreOffice vers SPIP. Il faut d’abord ouvrir le fichier dans un éditeur de texte. Et j’ai trouvé des limites, par exemple les notes sautent. Sachant que je fais des tests sur LinuxFR qui a un Markdown personnalisé. Ceci explique peut-être cela ou pas.
Le format ODF reste toutefois préférable à utiliser pour LibreOffice.
Bref, le gros problème du Markdown est de voir comment il est supporté. Pour autant que je sache, il y a quasiment autant de Markdown que de sites qui le supportent eu égard à sa légèreté. Sur LinuxFR, par exemple on écrit les exposants sous cette forme X^x j’ai vu que sur d’autres sites ça ne donnait pas le résultat attendu. Et on ne peut pas utiliser de balises html pour compenser. Ça il faut pouvoir les utiliser de toute façon.
Je sais bien que LibreOffice n’est pas SPIP. En revanche on peut utiliser LibreOffice pour rédiger pour SPIP.
Si cela vous intéresse, et aussi parce qu’il y a la question de la version de Markdown prise en charge. Et comme c’est matière à chipotage, ma dépêche sur LinuxFR.org concernant LibreOffice 26.2. Les commentaires peuvent être intéressants.
En clair, il faudra pouvoir indiquer la version de Markdown et les bibliothèques utilisées. Ceci juste au cas où personne n’y aurait pensé.
Personnellement deux points qui m’ennuient sont les exposants et la disparition des notes de fin et de bas de page.
Quand donc est-ce que ça te gêne ?
Une fois le squelette établi et les contenus stylés, on est pas sensé travailler sur le html généré alors je vois pas de quoi tu parles.
Quand donc est-ce que ça te gêne ?
Une fois le squelette établi et les contenus stylés, on est pas sensé travailler sur le html généré alors je vois pas de quoi tu parles.
C’est au niveau de la rédaction que c’est genant. En SPIP (et en latex d’ailleurs) tu écris ta note à l’endroit où va 'etre inséré l’appel de note. En markdown avec extension footnote, tu écris ton texte, tu fais un appel de note, puis tout en bas de ton texte tu ajoute tes notes.
Et du coup bah : si tu insère des nouvelles notes, si tu en déplace, etc, tu es bon pour revoir tout ton plan de note.
Exemple avec le code donné :
Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi[^note1] leo risus, porta ac consectetur ac.
[^note1]: Elit Malesuada Ridiculus
si tu veux ajouter une note après mollis tu es bon pour modifié à 2 endroits (après mollis, puis tout en bas), voire même à 4 (les deux note1 que tu dois modifier pour renumeroter en note2 histoire de ne pas être incohérent.
L’insertion de note « au fil de l’eau » à la SPIP / latex elle n’a pas cet inconvénient.
Le plus gros point immédiatement évident pour moi, ce sont les notes de bas de page de MarkDown, proprement merdiques par rapport à la syntaxe SPIP, comme Maïeul le rappelle. Dès le début, dès qu’on parle de Markdown, c’est le point qui m’inquiète et qui m’amène à d’autres questions: illico on perd, mais ce qu’on gagne me semble discutable.
À l’inverse, je crains aussi qu’une demande de Markdown, ce soit de faire du h2, h3, h4, h5, h6, alors qu’avec SPIP par défaut on est limité à faire des intertitres. Certes c’est limitant, mais ça force les rédacteurs à structure simplement et proprement leurs textes. Et par ailleurs, les pages avec du h3, h4, h5, h6, c’est impossible à maquetter (on fait en priorité des sites éditoriaux avec SPIP, mais des documentations techniques). Donc lors d’un passage à Markdown, j’aimerais bien qu’au moins par défaut, on ne se retrouve pas avec une infinité de choix de formatage, quasiment impossibles à gérer proprement dans les maquettes (avec la syntaxe actuelle et les plugins, c’est déjà souvent limite quand on développe des interfaces).
Perso, je n’ai eu aucun de différents clients qui se soit plaint d’avoir des raccourcis qui ne soient pas du Markdown. C’est certes infiniment plus répandu que les raccourcis SPIP, mais ce n’est pas non plus un «standard»: aucun de mes clients n’utilisait Markdown avant, et donc s’adapter aux raccourcis SPIP n’est jamais un problème parce que les gens qui gèrent des sites Web seraient déjà formatés Markdown.
Ou alors, l’idée ce serait une interface Wysiwyg, qui génèrerait du Markdown? Et là, franchement, je suis vraiment très dubitatif. Pour moi, toute la richesse et la finesse que j’arrive à avoir sur le texte de mes pages Web, c’est hors Wysiwyg: modèles, raccourcis ajoutés par des plugins, gestion ultra-poussée des insertions d’images, contrôle un peu poussé des vidéos… Et si on ne veut pas cette subtilité, franchement, les raccourcis {italique}, {{gras}}}, {{{intertitre}}} et sauter une ligne, même sans Wysiwyg, c’est vraiment pas usant à apprendre au point de devoir passer à une interface Wysiwyg.
SPIP est forcément plus compliqué et minoritaire qu’un Wordpress. Mais du coup, vouloir aller vers la simplicité d’un Wordpress, en perdant les richesses qui justifient qu’on utilise SPIP, je ne suis pas certain que ce soit un bon choix.
Je ne suis pas un spécialistes des autres CMS, forcément, mais du peu que j’ai constaté à chaque fois, les raccourcis SPIP (plus traitements automatiques, modèles et plugins), c’est une force énorme. (Je n’ai toujours pas réussi à activer une gestion typographique digne de ce nom avec Drupal. Il paraît que c’est faisable, mais bon, j’ai pas encore trouvé.) Perdre son originalité quand on est déjà ultra-minoritaire, je ne sais pas à quel point c’est une bonne idée. Vraiment: la gestion typographique de SPIP, non wysiwyg, où les choses ont été pensées, c’est une des grosses originalités de SPIP (par exemple un seul niveau d’intertitre de base, ce n’est pas une «erreur», dès le début ça a été un choix pour que les rédacteurs fassent des articles propres et structurés, pas de la «fausse» maquette comme ils l’ont toujours fait de manière désastreuse avec Word). C’est largement un des aspects qui justifie qu’on continue à faire du SPIP plutôt qu’installer un Wordpress tout fait tout clé en main.
Et donc je reviens à la remarque initiale des notes de bas de page. Je n’ai pas encore bien compris ce qu’apporte de plus le passage à Markdown pour les usagers, alors qu’il y a pas mal de points où je vois directement ce qu’on perd (notes de bas de page, perte des plugins qui restaient dans la logique SPIP notamment via Textwheel – ne serait-ce que si on ajoute des trucs via plugin, on perd de fait l’intérêt d’être dans un Markdown normalisé).
Il me semblait que Markdown permettait plusieurs types de notes suivant les habitudes de chacun⋅e justement : que tu pouvais faire des liens et tout regrouper en bas (en « block »), mais tu pouvais aussi écrire tes notes « inline » : [^](Ma note directement) ou ce genre de syntaxe. Mais il faut vérifier que notre interpréteur PHP sache le faire.
Sinon dans tous les cas tu peux mettre n’importe quoi comme ancre pas spécialement des numéros : la numérotation est censée être automatique.
@arno et bah tu continueras à utiliser le plugin/mode « syntaxe SPIP legacy » avec une interface années 2000 qui n’évoluera plus et voilà tout
Tout ce que tu dis là a déjà été argumenté il me semble :
il existe des implémentations de footnotes qui permettent en inline aussi
utiliser markdown permet d’utiliser des librairies déjà existantes, doublement avantageux :
aussi bien côté génération (pour nous les devs pour avoir moins de choses à maintenir tout seul que personne d’autres n’utilisent, ce qui est le cas de Textwheel),
que côté interface donc pour les utilisateurices à la fin, puisqu’il existe plein d’éditeur simple ou complexe (juste coloration ou WYSIWYG) qui gère markdown super bien
les règles typographiques dépendantes de la langue (espace, ponctuation etc) sont un tout autre sujet que la syntaxe d’écriture et ça ne devrait pas être mélangé. Tu peux écrire avec n’importe quelle syntaxe, et vouloir appliquer les règles de la langue cible dans tous les cas. Donc on peut parfaitement continuer de les appliquer avec Markdown.
le WYSIWYG/M ne poste aucun problème tant que tu permet d’éditer le texte source aussi (et que le WYSIWYG ne te l’efface pas quand tu reviens, qu’il laisse tel quel ce qu’il ne connait pas)
les modèles n’ont rien à voir avec la syntaxe d’édition, c’est un système supplémentaire pour inclure des templates dans les contenus : ça vaut quelque soit la syntaxe, et c’est toujours exactement pareil avec le plugin Markdown
et il y a déjà un plugin WYSIWYG pour Markdown (justement car il y a des briques existantes) et ce plugin gère les modèles graphiquement en plus, quand t’insères n’importe quel modèle (pas juste les images), ça te les génère dans ton texte en direct et tu peux même les rééditer après coup, sans avoir à connaitre par cœur les paramètres (tant qu’ils sont déclarés)
Il n’y a donc à peu près que des avantages pour les rédacteurices finales.
certes c’est moins pratique que les notes de SPIP, mais là, on fait avec ce qui existe (et déja merci à tofulm d’avoir fait l’implémentation de cette extension ^^)
Et garder la syntaxe SPIP en plus de celle de MD, pas possible ?
Bon, ça fait maintenir une truc hybride, certes, mais puisqu’on se donne déjà comme contrainte de gérer les modèles…
