SPIP Blog
Essayer la syntaxe SPIPPlutôt qu’un éditeur riche de type WYSIWYG, qui n’est pas idéal, parce que d’une accessibilité déplorable, SPIP propose une aide à la rédaction sous forme de raccourcis de saisie — c’est-à-dire un langage de balisage léger qui permet de rédiger pour le Web sans avoir besoin de connaître le HTML.
Cette syntaxe de rédaction est un des points forts de SPIP. Pourtant cet avantage est trop peu mis en avant. Il n’y avait, en particulier, pas de page en ligne qui explique ou montre ce qu’est cette syntaxe. En clair, il n’était pas possible de l’essayer sans devoir installer un SPIP, et c’est souvent après l’installation que les utilisateurices la découvrent, parfois sans comprendre ce que c’est…
Un article de la doc officielle présente les « raccourcis SPIP » et renvoie vers « l’aide en ligne ». Plus pratiques, quelques mémos existent, distribués sur SPIP-Contrib et dans la base de démarrage (voir celui-ci pour exemple). Mais ces ressources ne sont pas faciles à trouver : c’est qu’il faut avoir l’idée de saisir les termes « raccourcis SPIP » dans un moteur de recherche !
Comprendre la syntaxe SPIP, par la pratique
tetue rêvait donc d’un banc d’essai en ligne, public, qui permette d’essayer la syntaxe, sur la base de quelques exemples. Un truc qui permette de jouer de suite, et comprendre par la pratique, sans devoir lire préalablement des lignes et des lignes de doc, ni installer quoique ce soit.
Faisant suite à plusieurs articles d’affilés de tetue sur l’édition de contenus en balisage léger [*], RastaPopoulos s’y est attelé et, quelques lignes de code plus tard, c’est chose faite, joliment habillé du thème « Palatinesque » de nicod_ :
Ce banc d’essai public contribue à faire connaître la syntaxe SPIP, en la sortant de la confidentialité des espaces privés où elle était cantonnée. Servez-vous en pour en faire la démo et montrer à une utilisateurice, avant qu’ille n’installe SPIP, quelle sera la réalité de la rédaction. Ou en formation, pour former les nouveaux rédacteurices. Ou même, directement pour rédiger et formater un texte, hors contexte SPIP !
Partager la syntaxe SPIP
Il y a encore des améliorations à apporter, mais ce banc d’essai est déjà bien pratique. L’éditeur (dit « porte-plume ») pourrait être complété d’un mémo latéral des quelques raccourcis principaux — un peu comme l’interface suggérée par Nicolas Guilhou dans son coup de gueule : Brûlons les « traitements de texte » embarqués — et d’un lien vers une page exhaustive.
Si vous voulez participer, le matériel nécessaire à la fabrication de ce banc d’essai se trouve sur la zone, sous forme de plugin dédié.
Et après ? tetue rêve de rendre la syntaxe SPIP disponible hors SPIP. Qu’elle ait une existence autonome. Qu’on puisse l’utiliser pour rédiger en SPIP dans Dotclear, par exemple, ou dans n’importe quel wiki.
Car, bien que vieillotte, cette syntaxe est toujours pertinente : elle est très complète, davantage que le si populaire Markdown [*]. Elle mérite donc d’être partagée, pour étude, utilisation, inspiration, etc. Ne serait-ce que pour qu’on puisse se comprendre, entre utilisateurices et développeurices de différents outils de publication, en partageant nos pratiques.
Messages
26 décembre 2014, 09:56, par Mist. GraphX
« elle est très complète, davantage que le si populaire Markdown »
Oui peut-être, mais le but de markdown n’est pas d’être complet justement :
Le but de markdown est de garder le texte lisible, dans n’importe qu’elle circonstance, avec ou sans rendu, ou juste en simple fichier TXT : ce qui n’est pas le cas de la syntaxe spip !
Un article écrit avec la syntaxe spip est figé (utilisable que avec SPIP) et de plus quasi illisible, on peut même pas le passer a un correcteur orthographique ensuite comme Antidote par exemple avec toutes les accolades fermantes ouvrante ça plante.
Autre problème de la syntaxe spip et de ses tas d’accolades (pire quand on utilise TypoEnluminée avec les 5 niveaux de titres ^^), c’est l’imbrication des raccourcis et surtout l’oubli d’accolades fermantes : j’ai déjà passé bien souvent des heures sur un article très long qui cassait le site public, avant de trouver l’accolade qui manquait ... demandez a un rédacteur de faire afficher le code source, pour trouver dans le HTML la ou ça plante lol ...
donc commencer par avoir une coloration syntaxique dans l’éditeur texte de spip serait le bien venu, et un signalement des balises non fermées aussi ;-)
Donc hormis ceux qui rédige dans le navigateur directement en spip (le truc que personnellement je trouve un hérésie), je vois pas l’avantage...
Personnellement je n’utilise plus la syntaxe spip en tous cas,depuis bien 2ans, ... beaucoup d’éditeurs texte pour markdown sont sortis et permettent de rédiger avec la mise en forme et les css qui vont bien, depuis son ordi avec/ou en partage webdav/cloud, avec en plus un suivi git ou svn vu que c’est du fichier texte. En résumé on peut partager et rédiger ses articles a plusieurs, avec GistBoX ou GistHub, et avoir le suivi, la prévisue ...
Des librairies de conversion html<->md sont dispo et permette de la conversion de doc office ou libreoffice depuis l’export html, ...
Bref comme on dit souvent : pourquoi réinventer la roue ...
26 décembre 2014, 15:18, par RastaPopoulos
Personne n’essaye de réinventer la roue : la syntaxe SPIP existe depuis avant Markdown…
Quant à la complétude, désolé mais Markdown a été critiqué depuis le début pour le fait qu’il manquait des choses. Et ce n’est pas pour rien qu’il y a eu ensuite de nombreuses extensions ou versions alternatives, qui parfois se chevauchaient, et depuis peu la tentative de standardisation « CommonMark » par entre autre l’auteur de Pandoc. Donc si : au final, presque tout le monde cherche à avoir une syntaxe la plus complète possible, bien sûr en essayant de ne pas perdre en lisibilité.
Moi aussi je rédige régulièrement en MD, mais ça n’empêche pas que sa syntaxe des liens et des images est immonde et qu’elle est beaucoup plus lisible chez d’autres, notamment chez SPIP.
Moi ce que j’aimerais bien, c’est qu’il existe un compilateur syntaxique non basé sur des regex, mais vraiment sur un parsing correct, et qui ne soit PAS propre à une syntaxe. Un compilateur syntaxique configurable quoi (comme Textwheel mais pas en regex), avec un format pivot. Ça permettrait de programmer ensuite des compilateurs vraiment propres et de passer d’un format à un autre sans douleur et sans perte. Je ne sais plus si Pandoc fonctionne comme ça ou pas…
2 janvier 2015, 12:13, par Mist. GraphX
J’entends bien, je ne parle pas de la syntaxe, mais des multiples passerelles et autres outils qui sont déjà existant, pour notamment markdown, markdownExtra, GithUb Flavored ... etc. Gérés de plus déjà par Pandoc (faut avoir son serveur ou travailler en local).
Il est tout de même bien de pouvoir passer un article sur n’importe quelle, cms, wiki, ou autre comme le rêve Tetue et comme expliqué dans l’article, ou faire un epub ou pdf, et la la roue existe bien.
Par exemple je commence un site une a 10 pages avec Pico, je le passe sur Spip un an après car le besoins et le budget a évolué.
Markdown est une spécification un concept basé sur la lisibilité = si personne ne s’y tient ce n’est pas la faute de la spécification en elle même -> c’est idem pour celle de spip si on regarde les multiples additions qui y sont faites par des plugins et pas toujours heureuses :
exemple les niveau de titres de typo enluminée (que j’utilise sur tous mes sites utilisant la syntaxe spip d’ailleurs).
{{{** Titre de niveau trois }}}un rédacteur me met du gras dans un titre car il trouve ça joli
{{{** Titre de {{niveau trois}} }}}la on commence a avoir un problème pour lire, non ??? et encore j’ai mis un espace entre les accolades fermantes, les rédacteurs ne le font pas sur mes sites.
Sur spip on est limité a un seul niveau de titre à la base, et ça ça me dérange pour mon référencement et mes plans de page. donc la syntaxe markdown « out of the box » est déjà plus complète sur ce point ;-) .
Après j’utilise + markdown extra comme spec, et je ne l’ai pas trouvé limitée.. Les différents parsers le sont par contre : par exemple ParsedownExtra n’est pas aussi complet que MarkDown Extra, j’ai eut quelques surprises en passant de l’un a l’autre : donc quand on implémente sur un outils/cms, il est de bon ton de laisser le choix du parser suivant les besoins de l’utilisateur final.
13 juin 2015, 01:49, par anonyme
Bonjour,
Je rêve d’un SPIP qui soit vraiment souple, vraiment personnalisable et vraiment ouvert. Comme Debian l’est par exemple, quelques soient ses orientations en terme d’init (merci Devuan ;-) ou d’environnement graphique.
S’il était possible de remplacer le parseur et moteur de rendu SPIP par le parseur et moteur de rendu Dokuwiki, je resterai avec plaisir chez SPIP. Mais au vu des nombreux messages récurrents d’auto-satisfaction sur la « syntaxe SPIP », je doute fort qu’une telle liberté soit un jour autorisée dans le code même de SPIP.
Tant pis, avec l’arrivé de la version 3.1, je vais finir par abandonner complètement SPIP, même si cela me demande plus de travail en PHP orienté objet pour écrire mes plugins Dokuwiki.
13 juin 2015, 09:11, par RastaPopoulos
@anonyme
Ça c’est de l’auto-satisfaction sur la syntaxe SPIP ? Hum, interprétation bizarre…
À part ça il existe déjà un plugin pour remplacer la syntaxe SPIP par Markdown partout. Si tu veux t’en inspirer pour faire le même avec un compilateur Dokuwiki, libre à toi !…
Et sinon, amuses-toi bien avec Dokuwiki. :D