Dans le cadre du Skriv Markup Language, j’ai prévu qu’il soit possible de faire évoluer le langage grâce à un système d’extensions. Je viens de terminer la partie du site qui permet de proposer des extensions, de les commenter et de voter pour/contre.
Pour l’instant, quatre extensions sont proposées au vote public. J’en suis l’auteur, mais j’espère sincèrement que d’autres personnes vont se prendre au jeu et proposer à leur tour des idées d’évolutions.
À noter que je suis susceptible d’ajouter dans l’interpréteur PHP SkrivMarkup des extensions, même si elle n’ont pas été validées officiellement dans le langage ; elles ne seront juste pas activées par défaut. Le corollaire, c’est évidemment que les contributions en code source sont très appréciées elles aussi.
Toutes les personnes ayant une utilisation ou un besoin d’un système de balisage léger comme SkrivML (ou l’un des autres systèmes équivalents) sont invitées à venir participer, à voter pour les extensions, bref à créer une communauté visant à construire les meilleurs outils wiki-like.
Pour ceux qui avaient déjà voté sur les propositions d’extensions, je suis désolé mais j’ai dû tout remettre à zéro. Tout a été recodé, et il est maintenant obligatoire d’écrire un commentaire quand on vote sur une proposition. Encore toutes mes excuses, et je vous demande de bien vouloir revenir partager vos avis.
J’en profite pour lancer deux appels à l’aide :
- Si vous avez en tête des outils qui pourraient être utiles, associés au SkrivML, n’hésitez pas à m’écrire pour m’en faire part. On m’a déjà suggérer de faire une définition de syntaxe pour des éditeurs de texte, c’est une bonne idée. Autre chose ?
- Est-ce que vous connaissez des forums, des newsgroups ou d’autres espaces de discussion où il pourrait être utile de faire parler du SkrivML ? Je cherche évidemment à le faire connaître, mais je n’ai pas vu passer sur mon radar de tel lieu d’échange numérique…
Merci d’avance pour vos contributions.
SkrivML étant utilisé pour la rédaction de la documentation de atoum, je ne peux que me réjouir de cette ouverture, d’autant qu’à ce jour, la seule chose que je peux reprocher à la syntaxe que tu as créé est qu’elle n’est pas supportée par les éditeurs disponibles sur le marché actuellement.
Mais j’espère que cela va changer (l’idée d’en créer un m’a effleuré, mais j’ai déjà trop de projets en cours actuellement et je sais que je ne pourrais pas donner suffisamment de temps à un nouveau projet pour que le jeu en vaille la chandelle).
Pour les éditeurs, c’est vrai que c’est un frein. J’ai commencé à regarder du côté de SublimeText, sur un conseil de Renaud ; c’est multi-plateforme, mais c’est pas libre…
Je suis plutôt en train de travailler sur des outils web qui utilisent le SkrivML : Wiki, gestion de listes, écriture collaborative, …
Bonjour. La syntaxe est juste parfaite.
Y a-t-il un exemple de code d’une extension à télécharger ?
J’envisage deux ajouts : la spécification de dimensions pour les images, et une solution pour inclure des « shortcode tags » au sens de WordPress ( http://codex.wordpress.org/Shortcode_API ). Les « shortcode tags » permettent d’ajouter des éléments dans la syntaxe par du code PHP externe à celui de la syntaxe : c’est une option élégante pour inclure des vidéos par exemple.
Un détail. Lorsqu’on clique sur un item du menu dans la page « Official syntax », le titre est caché par l’élément fixé. Je suggère ceci :
h2 {border-bottom: 1px solid #DDDDDD;
margin-top: .8em; /* on garde une margin pour la fusion des marges */
padding-top: 1.2em; /* un padding plus haut que l'en-tête fixé */
}
En fait je me rends compte que les extensions sont peut-être en elles-mêmes des « shortcode tags ». Je ne trouve pas un exemple d’implémentation.
Concernant les images, je souhaite en outre pouvoir utiliser les éléments « figure » et « figcaption » pour ajouter des légendes. Idéalement il faudrait même pouvoir ajouter plusieurs éléments « img » qui se partagent une même légende « figcaption », il s’agirait alors d’un élément englobant mais la syntaxe serait alourdie. Peut-être qu’un simple paramètre supplémentaire ferait l’affaire ?
Ça donnerait quelque chose comme :
{{4.5x.72em|Skriv logo|http://skriv.org/logo.png|Ici la légende}}Mais les paramètres commencent à être trop nombreux. J’ai pensé à une syntaxe alternative qui viendrait en plus de celle actuelle : {{: }} et [[: ]] qui seraient strictement équivalents. Le premier mot venant après les deux points indique le type de balise (comme si c’était une commande vi). Ensuite viennent des paramètres nommés et en dernière position un éventuel contenu. Pour les paramètres, on pourrait par exemple en faire à la mode « 😐 » ou bien à la mode XML (je préfère).
{{:img|src:http://skriv.org/logo.png|legend:Ici la légende|alt:Texte alternatif|size:4.5x.72em}}{{:img src="http://skriv.org/logo.png" legend="Ici la légende" alt="Texte alternatif" size="4.5x.72em"}}
{{:span|class:highlighted|contenu du span}}
{{:span class="highlighted"|contenu du span}}
{{:a|target:_blank|href:http://skriv.org/|contenu du lien}}
{{:a target="_blank" href="http://skriv.org/"|contenu du lien}}
Je suggère aussi des commentaires façon latex « skrivisé ». C’est utile lorsqu’on rédige de grosses documentations :
%% le reste de la ligne est ignoré (sans générer non plus de commentaires HTML)@Cpag : Merci pour ton commentaire.
Il n’y a pas encore d’exemple d’extension, tout simplement parce qu’elles sont encore en discussion. Quand une extension deviendra « officielle », je l’ajouterai à la librairie, et cela pourra servir d’exemple.
Je ne prévois pas de supporter les balises « figure » et « figcaption ». Comme je l’ai écrit sur le site, «Un langage de balisage léger doit rester léger».
Ta proposition de syntaxe « {{: }} » est intéressante, mais trop différente du reste de SkrivML à mon goût. Par contre, on pourrait imaginer une extension permettant de gérer finement les images, dont chaque paramètre supplémentaire (après l’URL de l’image) serait utilisé directement :
<<img | http://url/image.jpg | alt=aaa | legend=bbb | class=ccc >>Tu peux faire une proposition d’extension sur le site 🙂
Mais sinon, si le but est d’appliquer un style à une image, il y a la possibilité d’utiliser les paragraphes stylisés :
{{{petite_image{{http://url.image.jpg}}
}}}
Concernant les commentaires, j’y pensais aussi, mais je réfléchis encore à une syntaxe satisfaisante.
Ah oui, très bien, les paramètres nommés des extensions sont une solution. On peut donc faire une extension « : » qui fournirait des balises inline paramétrées, ce qui donnerait par exemple :
<><>
<>
<>
Puis :
<>En discussion avec qui ? Je suis moyennement intéressé de monter le dossier de proposition d’une extension, je souhaite surtout implémenter ce dont j’ai besoin (puis partager ce qui est partageable 🙂 ).
Pour les commentaires le « %% » uni-ligne est satisfaisant. Les commentaires ouvrants et fermants ne sont pas imbriquables ni switchables aisément ce qui les rend peu pratiques pour mettre du code (ou du texte) en commentaire. C’est à l’éditeur de générer les commentaires unilignes sur plusieurs lignes. J’ai écrit un bouquin en Latex, je n’avais pas un éditeur capable de générer les commentaires sur plusieurs lignes et ça ne m’a pas manqué.