D’après ce que je comprends de la conversation c’est acté qu’il y aura les deux en parallèle. Perso je suis plutôt fan de la syntaxe Spip et de la philosophie qui va avec 
. Mais je comprends qu’il y ait pas mal de monde qui ait envie d’utiliser du Markdown qui est plus connu…
Merci @rastapopoulos, c’est intéressant.
Je continue un peu sur les questions:
-
il est mentionné #NOTES. Ça ne me semble pas anecdotique, parce que dans notre système, ça permet de décider de placer les notes où l’on veut, et pas forcément juste à la fin du texte de l’article (perso je travaille presque tout le temps avec 4 blocs de #TEXTE via un plugin, parfois encore j’affiche plusieurs articles à la suite sur une même page dans un long form… donc ne pas illico afficher les notes à la suite du pavé de texte qui les provoque, c’est bien pratique).
-
il est mentionné dans ce fil qu’il faut suivre une implémentation de Markdown donnée et ne pas faire n’importe quoi. Ça me semble effectivement logique si on veut profiter des avantages de changer de solution.
– Mais alors il ne suffit pas de dire «il existes des implémentations de footnotes inline», il faut que ce soit normalisé avec l’implémentation choisie.
– Par ailleurs, les modèles et les plugins (pas que des modèles), on peut bien dire que ça ne fait pas partie de Markdown, mais justement: on se retrouve à insérer des bizarre et non-standard dans un truc dont l’avantage est d’être standard. Donc je me méfie encore. Je sais bien que je suis très minoritaire à faire ce genre de choses, mais pour moi c’est tout l’intérêt de SPIP (en plus du système de squelettes): je fabrique des mini fonctionnalités de mise en page pour les besoins très spécifiques. Genre ceci, avec un raccourci tout simple (<bignum>Texte {{groschiffre}} Texte</bignum>). Ça n’est ni un modèle, ni du SPIP, et j’aimerais bien ne pas perdre cette souplesse.
-
Mais surtout, le point important pour moi, c’est que l’intérêt pour moi n’est pas dans gras-italique-intertitres, qui sont des fonctionnalités franchement pas compliquées et usantes, elles sont dans tous les ajouts qui, de toute façon, ne seront pas plus dans Markdown qu’elles ne sont de base dans le Textwheel natif de SPIP. Ce qui fait que les évolutions vers de la coloration, des changements de taille, voire du Wysiwyg, je suis très méfiant, si mes propres ajouts se retrouvent comme un cheveu sur la soupe dans une interface toute graphique pour les trucs pas usants (gras, italique, intertitres), alors que ce sont ces ajouts qui rendent extrêmement graphiques le contenu du texte (voir ma copie d’écran: si un éditeur ne rend pas ça, mais met en scène les fonctions de base, mon pavé “bignum” rendu comme du code, voire du code source, tout moche là-dedans, c’est plutôt contre-intuitif pour l’usager).
-
Si on met du Wysiwyg ou de la coloration, mais pour les modèle faut repasser en mode source (et certes on voit le résultat en rebasculant en mode Wysiwyg), c’est problématique:
– parce que ça promeut le fait de travailler dans deux modes, et les modèles et raccorucis supplémentaires deviennent accessibles uniquement en switchant dans l’autre mode; alors qu’actuellement tout est dans un mode unique; au lieu de simplifier, on ralentit ce qui est actuellement dans une interface unifiée;
– si vous avez un exemple d’interface Wysiwyg convaincante pour gérer les images, dites-le moi, je n’ai jamais rien vu de mon côté qui ne soit une uzine à gaz;
– et comme tu sais, pour les images dans les textes, je n’utilise pas les modèles standards, mais des variantes personnelles Insertion avancée d’images - Plugins SPIP avec plein de réglages spécifiques (|argeur=… , |rond, |kenburns, |flip, |large, |max, etc.). Du coup les interfaces de gestion des images Wysiwyg, déjà je trouve ça lourdingue, mais pour le coup ça tue mon truc. (J’ai aussi des choses pour les vidéos.) Par exemple une page de ce genre: Moyen-âge et Renaissance c’est beaucoup dans la construction du texte (notre sujet du moment, donc), et quasiment rien qui relève des raccourcis standards de SPIP (à part gras et italiquen tout le reste c’est du hors-norme SPIP).
Donc ce qui m’inquiète avec notre discussion, c’est qu’on se focaliserait sur les raccourcis standards (et hormis les notes, je suis assez confiant que SPIP ou Markdown ce sera assez kif-kif), histoire de rapidement basculer vers des éditeurs clé-en-main de Markdown, et qu’au final faire le genre de pages qui, pour moi, justifient toute la souplesse de SPIP, qui se font dans l’éditeur unique actuellement, deviennent une usine à gaz (de manière contre-intuitive) parce qu’on se retrouvera à jongler entre du Wisywig, des images gérées en interactif (généralement beurk), et une bascule vers du code source pour ce qui représente parfois l’essentiel de mes pages; ou dans le cas de coloration, des trucs assez plan-plan rendus super-graphiquement, et les extensions personnalisées, rendues moches.
2 « J'aime »
Pour le plus gros point, qui sont les ajouts « hors syntaxe dans tous les cas », tu te réponds déjà à toi-même non ?
Si dans tous les cas on parle d’ajouts qui n’existent dans aucune syntaxe, baaaaah : tu as bien dû faire l’effort de les ajouter pour SPIP donc tu dois bien pouvoir le faire pour Markdown aussi. Ce ne sera plus Textwheel, donc forcément il faudra les recoder dans un nouveau système. Mais la lib PHP utilisée pour Markdown a bien des points d’entrées pour faire des extensions de toute sorte donc forcément tu pourras recoder pareil. Extensions - CommonMark for PHP
Toujours pour tes extensions mais pour le WYSIWYG : si pour tes besoins, tu penses qu’au niveau UX des rédacs c’est bien qu’ils voient tes extensions persos aussi bien dans l’éditeur WYSIWYG que dans la génération finale du site (ce qui est souvent le cas), alors forcément il faudra coder tes extensions à la fois en PHP et en JS. Car c’est pas un mystère, nous SPIP on est full PHP, mais par contre les éditeurs live and direct c’est forcément du JS. L’éditeur TipTap qui est implémenté pour l’instant a de nombreux moyens d’étendre aussi (j’ai déjà fait des extensions pour les modèles par exemple).
Mais si tu as la flemme, tu peux aussi juste dire qu’on les tape dans l’éditeur… comme avant, et alors afficher les balises autour des contenus et ça sera uniquement dans le PHP final que ça sera généré. Évidemment, pour être carré et sympa avec les gens, je conseille bien sûr de faire l’effort de coder les extensions pour le parseur PHP et pour l’éditeur JS.
Et donc je rebondis, sur les modèles : si tu sais faire des modèles, tu sais les déclarer dans un YAML en décrivant TES options possibles. À partir de là à aucun moment je n’ai parlé d’alterner entre code source et visualisation : je t’ai dit que les modèles sont bien ajoutables ET modifiables directement en WYSIWYG (tant qu’ils sont déclarés). Et c’est mille fois mieux pour les rédacteurices, qui n’ont pas à se souvenir des 36 paramètres que tu leur as documenté ya 3 ans : l’interface leur montre des input text, des selects, des cases à cocher, etc suivant tes options déclarées.
2 « J'aime »
à priori c’est OK non seulement dans le plugin Markdown mais aussi dans Markdown editor (l’éditeur WYSIWYG )
…et idem pour le <html>...ici du html brut...</html>
pour l’instant c’est le cas : le plugin Markdown donne le choix :
…mais en revanche le plugin Markdown editor ne fonctionne que si tu es en configuration Markdown…
Ceci étant dit, la question du passage à MD « par défaut » (en SPIP 6 ?) s’est d’abord posée dans une optique de diminuer la quantité d’éléments de SPIP spécifiques pour essayer d’utiliser des lib plus « génériques », développées par une communauté large. Typiquement ici utiliser CommonMark de phpleague pour ne plus avoir à maintenir/développer TextWheel
Dans cette optique il me semble qu’on s’éloigne grandement du but si on se met comme contrainte de conserver une double implémentation !
AMHA une fois qu’on aura une solution MD robuste, logiquement le maintient de la syntaxe SPIP (i.e. Textwheel) devrait reposer sur un plugin, donc devenir facultative
à priori, en tous les cas tel que c’est fait pour l’instant tu n’as strictement rien qui t’oblige à switcher en MD comme format de stockage et quand bien même tu choisirais d’utiliser le MD, tu ne seras pas plus obligé d’installer/activer le plugin WYSIWYG…
=> tu peux donc décider que tes utilisateurs sont suffisamment débrouillés en code SPIP pour continuer de fonctionner à l’identique…
Mais de mon côté j’ai à la fois des auteurs (des profs en particulier) qui ne veulent surtout pas faire l’effort d’avoir à mémoriser quoi que ce soit comme raccourcis typo (on leur impose l’utilisation de SPIP dans un cadre professionnel alors il faut que ça soit « 0 efforts ») d’où la nécessité d’un éditeur WYSIWYG (le code généré ils s’en f***ent !)
…et d’autre part j’ai des auteurs (des chercheurs en particulier) qui sont des utilisateurs au quotidien de MD dans leurs outils et qui sont de ce fait demandeur de ne pas avoir un autre pseudo-langage à apprendre.
1 « J'aime »
Ça devient le mien au fil du temps.
Et le compromis des distributions SPIP me semble la meilleure solution pour releaser SPIP5 à la date souhaitée, ou plutôt 2 SPIP5: un à la date souhaitée (dans moins de 5 mois) et un quand le chantier MD sera mature.
La question initialement posée c’est « Markdown par défaut dans SPIP5 ». ça me paraît pas du tout prudent. Si l’ambition c’était installable/activable dans SPIP5 et éventuellement par défaut dans SPIP6, ce serait défà plus safe en terme de dépréciations, migrations, etc.
Ce serait plus confortable pour gérer le Breaking Change, pour tout le monde.
2 « J'aime »