Forums Casio - Vie communautaire

Index du Forum > Vie communautaire > Le langage de forum de la v5 - Lightscript (RFC)
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Posté le 02/01/2018 14:50

Le langage de forum de la v5 - Lightscript (RFC) :

Salut à tous ! Je voudrais vous présenter le draft actuel du langage de forum de la v5 - nommé Lightscript, un gentil dérivé de Markdown conçu pour Planète Casio. J'ai noté RFC (Request For Comments) dans le titre, c'est une manière fun de dire que vous êtes invités à donner votre avis !

2018-02-06 : La spécification est freezée jusqu'à nouvel ordre ; j'implémente. Vous pouvez quand même faire des remarques ou proposer des extensions, elles sont bienvenues !

Ce langage servira à écrire tout ce qui existera sur la v5 ou presque : les messages sur le forum, les descriptions et commentaires de programmes, les tutoriels, les messages privés, etc etc. Les seules exceptions notables que je puisse déjà évoquer sont les tutoriels, que l'on pourra aussi écrire (au choix) en LaTeX, et l'IRC qui fait bien ce qui lui plaît.

Je tiens à préciser que je suis en train d'implémenter le programme de conversion (vers HTML), mais je débute encore. Rien n'est définitif, tout est discutable.

La description du langage est ci-dessous : vous pouvez réagir sur l'ensemble ou pointer des conflits de syntaxe, des oublis, des fonctionnalités manquantes qui vous sembleraient intéressantes. Il y a des choses que j'ai éliminées volontairement ; je les ai citées tout à la fin avec un argumentaire. N'hésitez pas à en discuter. Je compte sur vous !

Le modèle « théorique »

Sans rentrer dans les détails compliqués, un message en Lightscript c'est une suite de blocs : paragraphes, citations, listes à puces, titres par exemple. La fin d'un bloc est soit marquée explicitement par la syntaxe (comme les citations qui se terminent toutes par >>>), soit marquée par un retour à la ligne ou par une ligne vide. C'est important, donc soyez attentifs !

Beaucoup de blocs contiennent du texte interprété (par exemple les paragraphes ; mais pas les blocs de code, dont le contenu est recopié tel quel dans le HTML). Le texte interprété peut contenir des objets textuels, par exemple un passage de texte en gras, un lien hypertexte, ou une référence à un programme dans la base de données.

Passons maintenant aux réjouissances.

Détail des blocs

Les paragraphes sont exactement ce que vous pensez. Un paragraphe représente une unité de texte « par défaut », et se termine habituellement sur une ligne vide. Il peut contenir des retours à la ligne, qui sont alors fidèlement reproduits (ce qu'on fait actuellement dans la v42). Quand vous sautez une ligne, un nouveau paragraphe commence. Savoir si plusieurs lignes vides sont fusionnées en une seule n'est pas encore décidé !

Comme en Markdown, je vous propose deux styles de titre : soit avec des #, soit soulignés. Le premier type, c'est un ou plusieurs # suivis d'un paragraphe. Ça va donc jusqu'à la prochaine ligne vide. Le second type (décoratif), consiste en un paragraphe souligné par des = ou des -. La ligne qui souligne indique très naturellement la fin du bloc de titre.

# Titre de page

## Titre de catégorie. On a le droit de le
prolonger sur plusieurs lignes

...

###### Titre de niveau 6

Titre de page alternatif
========================

Titre de catégorie alternatif
-----------------------------

Les citations et les blocs de code ont une syntaxe commune : ils commencent par trois symboles ouvrants sur une ligne (avec des options facultatives) et se terminent par trois symboles fermants sur une ligne. Les symboles doivent être placés au tout début de la ligne, sinon ça fait un paragraphe !

>>> DarkStorm
Oui. Il suffit de la coder. :waza:
>>>

``` basic lines
Getkey→G
G=47⇒Goto 9
G=27⇒X-1→X
G=37⇒X+1→X
```

Niveau listes, je propose des listes à puces et des listes ordonnées. Pour les listes ordonnées, la numérotation commence par le nombre indiqué sur la première ligne puis incrémente les numéros en ignorant les valeurs suivantes (c'est classique) ; ça vous évite de tout renuméroter chaque fois que vous insérez un truc.

- Ceci est une liste à puces
* Elle continue même quand on change de puces
+ On peut y mettre du `code`, du *formatage*...

0. Real developers count from 0
1. No, real developers use butterflies!
2. Ah, yes, there's good ol' C-x M-c M-butterfly for that.
3. Damn, Emacs...

Il me reste les définitions de références. Parfois les liens de la forme [label](url) sont lourds à lire parce que l'URL est longue, parfois vous voulez utiliser plusieurs fois la même URL. Dans ce cas, vous pourrez écrire [label][ref-name] et définir plus loin la valeur de ref-name. C'est ce que j'appelle une définition de référence !

[ref_name]: http://www.example.com

Une définition de référence tient sur une unique ligne. Je reviendrai sur ces liens dans la section suivante !

Les objets textuels

C'est là qu'on s'amuse à mettre n'importe quoi dans nos phrases. Commençons par les options de formatage :

*emphasis*               (italique)
**strong**               (gras)
~striked~                (barré)
`code` ou `code`[lang]   (code inline)
$math$                   (formules KaTeX)

Je pense que tout est à peu près explicite. Le cas `code`[langage] permet de mettre du code coloré dans une phrase. Il ne faut pas d'espace entre la backtick fermante et le premier crochet !

Les liens sont toujours une question délicate. La détection automatique des URLs dans les messages (autolinking) est compliquée à écrire et à utiliser, donc je vous propose de simplifier votre vie (et la mienne !) en mettant des chevrons (<url>). De façon générale, prenez le temps de mettre des noms sur vos liens, ce sera toujours supérieur !

Des liens, il y en a plusieurs types : certains sans noms, d'autres avec. En spécifiant un # au début de l'URL, vous pouvez référencer une section de votre article/tutoriel, ça enverra vers le titre associé !

<http://example.org>
[lien externe](http://example.org)
[lien interne](#compilation-manuelle)

Vous pouvez également décider de spécifier l'URL plus tard, à l'aide d'une référence (rappelez-vous, le bloc de définition de référence sert à ça !). Vous pouvez aussi utiliser une ressource (voyez plus loin) comme cible, ou tout simple une page de Casio Universal Wiki.

[lien par référence][ref-name]
[lien vers ressource][:uLephenixnoir]
[lien vers le wiki][[Basic Fx-CG]]

Comme avant, il y aura des médias. La syntaxe pour les utiliser est assez générale :

[[image:http://url.png 640 480]]
[[video:youtube.com/watch?v=deadbeef]]
[[wiki:Fxlib.h]]

Je n'ai pas encore fixé le type de choses qu'on pourrait utiliser avec ; je vous invite à suggérer. Le comportement pourra être différent si cet objet est utilisé en plein milieu d'une phrase ou tout seul sur un paragraphe. Par exemple, on aura envie de centrer les images si elles sont toutes seules.

Viennent ensuite les spoilers. Les discussions ont été longues et compliquées. Pour tenter de concilier les partis, je vous propose un spoiler volontairement moins puissant que l'original. C'est un spoiler inline, et vous ne pouvez donc mettre que quelques phrases dedans. Vous pouvez le tester sur jsfiddle.net :


And then they (((all die)))!

Il reste les choses les plus fun. D'abord les notes de bas de page (pour l'humour dans les articles en page d'accueil ^-^ ), et ensuite les références aux objets de Planète Casio :

Oui, mais c'est impossible ! [^Sauf si P=NP.] (note de bas de page)
:m2451 (référence au message numéro 2451)
:f234 (topic numéro 234)
:t32 (tutoriel numéro 32)
:rLephe/gint (dépôt Gitlab `Lephe/gint`)
...

Toutes les références de Planète Casio utiliseront la syntaxe :[a-z][^ :]+ (c'est-à-dire, ":" suivi d'une lettre minuscule suivi d'un mot non vide qui ne contient ni espace ni ":") et elle leur est strictement réservée. Cela n'interfère pas avec nos smileys !

On peut aussi utiliser ces références dans des liens (quand c'est approprié). Par exemple :

[Profil de Ne0tux][:uNe0tux]

Vous avez aussi les mentions : de gens, ou de groupes. L'usage des mentions de groupe trop larges type @@all sera probablement réservé à l'équipe pour éviter des problèmes :

Je pense que @Cakeisalie5 connaît la solution à ce problème.
Topic à nettoyer (@@mod).
@<pseudo>
@@all @@admin @@mod @@redac etc.

Il me reste, finalement, les smileys. Vous les connaissez assez bien pour ne pas avoir besoin d'une description. Je ne vous cache pas que j'aimerais bien remplacer les grands par des choses de taille raisonnable, ou les supprimer. Dans tous les cas, il y auras probablement de légères retouches de design sur les smileys habituels (presque rien).

Subtilités de syntaxe

Si vous n'avez pas envie de vous casser la tête, sautez cette section. Si vous pensez que la syntaxe ne va pas tenir le coup, lisez-la ; vous aurez peut-être des réponses. Si non, prévenez-moi dans les commentaires !

Pour le formatage des objets textuels, vous pouvez avoir envie de mettre un backtick dans le code. Pour ça, doublez les backticks sur le côté. Tout ce qu'il faut c'est que le code intérieur ne contienne pas la marque de fin. S'il apparaît des backticks, mais pas en même nombre, ce n'est pas grave :

``$ cat `find -iname *.c` | grep MACRO``
`function(``args``);`
```function(``args``, `arg`);```
  -- ` et `` sont tous deux présents dans le code, donc on triple

Pour le gras et l'italique, c'est pareil, sauf qu'une fois tous les comptes terminés c'est la parité du nombre d'étoiles qui détermine le type de formatage que vous demandez (impair : emphasis, pair : strong). Ça marche aussi pour les citations imbriquées (et le code, comme vous vous en doutez) :

>>>> DarkStorm
>>> Eragon
Ok sinon il y a un moyen de tester la V5?
>>>
Oui. Il suffit de la coder. :waza:
>>>>

Je prévois que le bouton « Citer » calcule automatiquement un nombre satisfaisant de chevrons si le message à citer contient lui-même des citations. Faut pas déconner non plus !

Éléments à potentiellement ajouter

J'en ai déjà cité quelques-uns. Il me vient à l'esprit :

– De quoi centrer ou justifier le texte (paramètre du message)
– Des tableaux pour faire des statistiques *o*
– Les barres horizontales (facile à faire ça)

Éléments intentionnellement omis

Avec les discussions, j'ai mis à jour cette section. Voilà ce qui en reste ; les objets qui sont pour l'instant éliminés... avec explications.

Les spoilers ont été réduits à des objets inlines pour éviter qu'ils soient utilisés pour structurer les descriptions de programmes ou des grosses docs qui devraient être séparées en plusieurs pages. Le gameplay d'un jeu ne devrait pas être caché dans une boîte ! C'est le plus important. Les titres sont plus appropriés pour structurer et les grandes images seront redimensionnées automatiquement, donc cette restriction ne devrait pas gêner outre mesure. J'ai pu oublier des cas.

Le soulignement et le texte barré sont rarement utilisés. Le gras remplit efficacement le rôle de mise en avant prévu par le soulignement, et comme Lightscript ne précise pas ce que <strong> donne comme formatage, on peut aussi opter pour italique/soulignement sans gras. Le texte barré est difficile à lire. Honnêtement, j'ai surtout éliminé ces deux-là pour des raisons de syntaxe. J'ai eu trop de mal à trouver des moyens honnêtes de les introduire dans la définition du langage.

Les liens vers une page de profil et les barres de progression étaient compliqués à intégrer à la syntaxe, mais je peux réfléchir au premier avec la syntaxe réservée, par exemple :uLephenixnoir. Le second n'a à ma connaissance jamais été utilisé de façon productive, à part pour poster des commentaires de programmes qui balançaient un chiffre au lieu de donner des éléments intéressants sur l'état de développement des projets. On s'en passera sans peine, je pense.

Conclusion

C'est un très long post, je vous remercie de l'avoir lu jusque-là. Vous avez certainement des remarques à faire : j'y répondrai de mon mieux. Merci de votre aide !



Pages: 1, 2, 3, 4 | Suivante

Zezombye
En ligne
Rédacteur
Points: 1134
Défis: 12
Message
Citer : Posté le 02/01/2018 15:06 | #
Le remplacement du BBcode est une très mauvaise idée selon moi (s'il est remplacé, vu que je n'ai pas vu d'indication contraire). Etant donné que la quasi-totalité des forums utilisent du BBcode, les utilisateurs y sont habitués, et changer ça pour le markdown (que je n'ai rencontré que sur reddit, personnellement) entraînera de la confusion.

Le lightscript étant un dérivé du javascript, je pense qu'il faudrait changer le nom.

Utiliser les backticks est bien chiant parce que sur les claviers azerty, le backtick est une touche morte. Donc si je veux écrire int i ça donne ìnt i. Je suggère d'ajouter le caractère ¤ dont personne ne se sert, ainsi ¤int i¤ serait mis en code.

Les spoilers devraient être conservés car ils sont bien utiles. Dans la page de BIDE, la moitié du texte est en spoiler : normal, elle n'est pas nécessaire à l'installation et sert à des cas spécifiques. Si on enlève les spoilers, on devra scroller beaucoup plus, et on ne pourra pas distinguer entre information nécessaire et spécifique. Après, c'est vrai que les auteurs de topics/programmes doivent bien utiliser les spoilers et ne pas mettre d'informations nécessaires (telles que les touches, gameplay, etc) dedans, mais enlever les spoilers n'est pas la solution.

Franchement je suis contre l'enlèvement du BBcode, ça oblige les utilisateurs à apprendre une nouvelle syntaxe dont ils ne se serviront que sur ce forum. Après je pense que rien n'empêche les 2 de coexister (comme c'est le cas avec les backticks actuellement).
----------------------------------
Divers jeux : Puissance 4 - Chariot Wars - Sokoban
Ecrivez vos programmes basic sur PC avec BIDE
Breizh_craft
En ligne
Modérateur
Points: 753
Défis: 7
Message
Citer : Posté le 02/01/2018 15:06 | #
Ça me semble pas mal du tout, j'ai peut-être loupé des trucs.

Le barré est très utile pour l'humour, aussi pourquoi ne pas l'implémenter comme le M↓ le fait de base, à savoir ~ainsi~ (là aussi, les tildes peuvent être prolongés).

Le soulignement on oublie, je suis d'accord. Il est également oublié dans le Mardown et pas mal de langages de ce type. Il est également souvent déconseillé.

Les spoilers peuvent servir pour les images lourdes, ou les codes de bourrin. Ou simplement pour le suspens ou… le spoil (solutions de jeux, etc…). Même si effectivement, actuellement, ils sont souvent mal utilisés…

Ajouté le 02/01/2018 à 15:09 :
Le BBCode est lourd et rarement utilisé directement (généralement avec des boutons). De plus en plus de forums et blogs acceptent le Markdown pour les commentaires (Zeste de Savoir, et pas mal de blogs, dont j'ai plus les liens, qui utilisent des trucs tout fait acceptant le Markdown. RocketChat aussi l'accepte).

On peut mettre ~ en alternative au backticks (en conservant les backticks, et uniquement pour les blocs, vu ce que j'ai dit plus haut), comme pas mal de variantes du Markdown l'acceptent.

Ajouté le 02/01/2018 à 15:19 :
D'ailleurs, on a une syntaxe pour les tableaux ?
----------------------------------
Informagicien professionnel, prestidigitateur système. Tout est possible.
Zezombye
En ligne
Rédacteur
Points: 1134
Défis: 12
Message
Citer : Posté le 02/01/2018 15:20 | #
Le BBCode est lourd et rarement utilisé directement (généralement avec des boutons). De plus en plus de forums et blogs acceptent le Markdown pour les commentaires (Zeste de Savoir, le blog de Korben…)


De toute façon il faudra des boutons pour le markdown, vu que c'est inconnu à la plupart des utilisateurs. Personnellement j'écris le bbcode directement, le nom des balises est plus facile à retenir que le symbole à utiliser (après, c'est une histoire de status quo, si les forums utilisaient tous le markdown j'aurais retenu le markdown).
Les forums qui acceptent le markdown sont plus souvent des forums de programmation, les forums de jeux, aide technique, etc utilisent toujours le bbcode.

On peut mettre ~ en alternative au backticks (en conservant les backticks), comme pas mal de variantes du Markdown l'acceptent.


Ca marche pas non plus, le ~ est aussi une touche morte. Il n'y a pas le problème avec le int i mais ça posera problème avec le ã ou õ, et bien sûr le fait qu'il faille appuyer 2 fois sur espace pour faire un tilde et une espace.

Sans rentrer dans les détails gores, un message en Lightscript c'est une suite de blocs : paragraphes, citations, listes à puces, titres par exemple. La fin d'un bloc est soit marquée explicitement par la syntaxe (comme les citations qui se terminent toutes par >>>), soit marquée par une ligne vide. C'est important !


C'est surtout très chiant. Si c'est ce que je pense, c'est comme sur reddit : pour marquer la fin d'un paragraphe, il faut passer une ligne, sinon la ligne continue. Ca provoque beaucoup de confusion et c'est totalement inutile. Si je retourne à la ligne comme ici,
il faut que ce soit affiché et non pas ignoré.
----------------------------------
Divers jeux : Puissance 4 - Chariot Wars - Sokoban
Ecrivez vos programmes basic sur PC avec BIDE
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Citer : Posté le 02/01/2018 15:32 | #
Le remplacement du BBcode est une très mauvaise idée selon moi (...) la quasi-totalité des forums utilisent du BBcode, les utilisateurs y sont habitués, et changer ça pour le markdown (...) entraînera de la confusion.

C'est légitime, mais si on y réfléchit :

- La « quasi-totalité » dont tu parles utilise phpBB, un forum écrit en PHP. Est-ce une raison pour faire pareil ? phpBB n'est plus un forum moderne depuis longtemps... et Discourse supporte le Markdown.
- Discord supporte le Markdown. Nos utilisateurs ne sont pas stupides ; ils connaîtront.
- Si je peux me permettre d'être tranchant, BBCode est une immondice. Il y a des crochets de partout, aucune notion de sémantique, et j'ai pas envie de coller une balise [gitlab-issue]lephe/gint#4[/gitlab-issue].
- Beaucoup d'utilisateurs utilisent les boutons du haut pour écrire leur texte : la preuve, on retrouve souvent du code coloré qui ne fonctionne plus (depuis que Cake a mis à jour l'interpréteur), ou le smiley 8) qui s'écrit désormais 8-) mais n'est toujours pas à jour dans le bloc de droite.
- On n'est pas des tyrans, il y aura un bouton d'aide au-dessus de la boîte de texte. Et des indications.

Le symbole monétaire, ¤ ? Euh, je veux bien être ouvert aux suggestions, mais là tu vas 100% rendre les utilisateurs confus. Si ton clavier est mauvais, change ton agencement, ou appuie deux fois sur la touche. Ou alors, suggère un caractère alternatif, mais... viable, si possible.

Je comprends le besoin de répartir les informations dans ton topic sur BIDE, mais je ne trouve pas ton usage des spoilers légitime dans ce cas. Y'a plein d'informations. Une vraie solution serait de mettre une synthèse des fonctionnalités sur cette page et des références au wiki de ton outil sur le Gitlab de Planète Casio, où tout serait détaillée dans ta documentation.

Tu vas me dire (à raison), « personne ne fait ça, les gens ne vont pas aller lire », mais ça ne deviendra pas une pratique commune tout seul. Virer les spoilers incitera à faire ce genre de choses... sérieusement. Quoi qu'on en dise, ça reste une solution plus viable qu'un gros paquet de texte, il me semble. BIDE est un projet conséquent. C'est réducteur (et illusoire) de vouloir le faire tenir sur une seule page. (Planète Casio a un peu tort de ne t'offrir qu'une page pour en parler, aussi. Heureusement, il y a les wikis du Gitlab, désormais.)

Je vais quand même voir ce qu'on peut faire avec les spoilers. Honnêtement, je les déteste. Et je ne vois aucune manière élégante de les ajouter à la syntaxe. Je suis preneur de suggestions.

Pour Breizh_craft, on peut rajouter le barré avec ~, mais dans ce cas-là on ne peut pas l'utiliser pour le code.

Edit :
De toute façon il faudra des boutons pour le markdown, vu que c'est inconnu à la plupart des utilisateurs.

Laisse-moi en douter plus que fortement.
----------------------------------
Rise.
Nemhardy
En ligne
Grand maître des Traits d'Esprit
Points: 1206
Défis: 54
Message
Citer : Posté le 02/01/2018 15:42 | #
Breizh_craft a écrit :
Le barré est très utile pour l'humour

+1


Sinon, ça me semble intéressant.
La syntaxe pour les citations me semble un peu étonnante, j'ai du mal à dire pourquoi ceci-dit. À l'usage on s'y fera de toute manière, et si c'est effectivement bien plus commode à parser, allons-y !
Les références, ça va être chouette aussi !

Pour la disparition des spoilers, vu qu'on peut controler facilement la dimension des images, je ne vois pas d'intérêt fondamental.

Pas grand chose à dire finalement ; j'ai l'impression qu'on sera capable de s'adapter à à peu près tout de toute manière, et tant que le formatage essentiel (gras, italique, …) est accessible simplement pour l'utilisateur pas forcément habitué, ça ne posera pas de soucis je pense.
----------------------------------
Ils n'osent pas s'avouer que c'est à cause de rien du tout…
Dark storm
Hors ligne
Administrateur
Points: 10319
Défis: 174
Message
Citer : Posté le 02/01/2018 16:33 | #
Pour les spoilers, il me semble qu'on avait proposé la syntaxe suivante :
((( Spoil de Star Wars
À la fin, ils meurent.
)))


À voir si c'est jouable, mais de toute façon si spoiler il y a, ils seront limités à un seul et unique niveau.
----------------------------------
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Páranÿe quetë Quendya
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Citer : Posté le 02/01/2018 16:41 | #
C'est surtout très chiant. Si c'est ce que je pense, c'est comme sur reddit : pour marquer la fin d'un paragraphe, il faut passer une ligne, sinon la ligne continue. Ca provoque beaucoup de confusion et c'est totalement inutile.

S'il vous plaît, ayez un peu de considération dans votre ton pour le mec qui en est à la 5ème version de son draft et qui y a probablement plus réfléchi que vous... merci.

Je suis prêt à argumenter sur ce point. Il y a, à peu près partout, deux façons de revenir à la ligne : soit tu reviens simplement à la ligne (line break), soit tu commences un nouveau paragraphe. Les traitements de texte connaissent très bien ce principe : Entrée démarre un nouveau paragraphe, Shift + Entrée revient à la ligne sans provoquer l'indentation classique du nouveau paragraphe.

LaTeX connait aussi ça très bien. Surtout que les sources LaTeX ressemblent pas mal à du code donc sont parfois obligées de revenir à la ligne pour éviter de sortir des lignes trop longues. LaTeX, pas con, transforme ça en espaces. HTML l'a bien compris aussi. Bon, lui attend carrément un <br> explicite pour passer à la ligne suivante... on peut faire mieux que ça.

Markdown possède le même concept. Il transforme par défaut les retours à la ligne en espaces, mais conserve un line break si la ligne se termine par au moins deux espaces consécutifs. Le changement de paragraphe se fait en laissant une ligne blanche parce qu'il faut bien une syntaxe différente.

Moi je trouve que ça a du sens. Après tout, le retour à la ligne n'est pas un truc usuel dans les textes bien écrits. Dans les livres, il y a des paragraphes indentés. Les retours à la ligne sont inexistants ou presque. Dans un article bien écrit, je trouve ça naturel que le paragraphe soit préféré sur le retour à la ligne.

Les paragraphes ont aussi l'avantage de bien aérer le texte et de structurer le propos. Ne0tux s'est battu un moment pour qu'on se défasse de l'idée qu'il postait toujours des pavés et a allègrement utilisés de sauts de ligne pour aérer ses messages. (Je n'ai pas pu retrouver le post où il l'expliquait, mais je me souviens de l'histoire. Il confirmera peut-être.)

C'est aussi parce que je saute des lignes que ce message est lisible.

Je comprends le paradoxe : M↓ est fait pour être, d'une certaine manière, du type What You See Is What You Get, mais il ne s'accorde pas sur les sauts de ligne. À mon avis, la raison pour ça est que M↓ reste un markup du genre qu'on édite dans un éditeur de code, et non un langage pour un traitement de texte. Dans un fichier de code, on se soucie de la longueur des lignes, et fatalement, on est obligés de ne pas recopier telles quelles les fins de lignes. J'espère que tu m'accorderas ce point.

Je me souviens également du topic de philo, où j'avais discuté par pavés avec Louloux, tellement que ça avait créé de la confusion sur nos intentions. Dans tous les cas, la discussion a du être arrêtée et n'a pu reprendre que lorsqu'on a eu reformaté nos messages pour les structurer. Une bonne partie de ce travail a été de remplacer des retours à la ligne par des lignes blanches.

Maintenant, j'espère aussi que la v5 verra un attachement plus sérieux à écrire de bons articles, des messages structurés et un français correct. À partir de là, on peut déjà aller assez loin. Ce n'est donc pas paradoxal à mes yeux que le paragraphe soit l'unité « privilégiée » par le langage.

Pour quitter mon propos sans fin et revenir sur tes arguments, je ne pense pas que ça créera plus de confusions que la présence d'une syntaxe M↓... ne serait-ce que parce que M↓ fonctionne comme ça. Ça incite aussi les gens à structurer leur propos, je pense que c'est un point positif. On en revient à la question de « changer les habitudes pour essayer quelque chose de mieux » (à condition évidemment, que mon argumentaire soit suffisamment convaincant pour aboutir au fait que les paragraphes sont plus intéressants que les blocs avec de simples retours à la ligne).

Quant à savoir si c'est inutile... c'est assez subjectif. En fait je peux légitimement accuser les retours à la ligne d'être inutiles dans la plupart des situations. Peux-tu défendre leur existence, pour commencer ?

Voilà, j'espère que ce gros message n'effraiera personne mais vous incitera à argumenter encore plus. N'imaginez pas que j'ai imaginé ça en 20 minutes tout à l'heure. Cette proposition est sans discussion imparfaite, mais résulte de suffisamment de réflexion pour que vous preniez le temps d'argumenter, je pense.
----------------------------------
Rise.
Zezombye
En ligne
Rédacteur
Points: 1134
Défis: 12
Message
Citer : Posté le 02/01/2018 16:58 | #
Selon moi les retours à la ligne et paragraphes ont chacun leur raison d'exister. Je ne trouve pas grand chose sur internet, mais par exemple avant une liste, ou pour plusieurs affirmations (cf ce message par exemple).

Le problème est plus qu'il n'y a aucune raison d'ignorer les retours à la ligne. C'est peut être utile avec le truc des 80 colonnes, mais ça s'applique pas sur ce forum. Ca va juste rendre les utilisateurs confus, on s'attend à ce que *test* fasse test, on s'attend pas à ce que les retours à la ligne soient ignorés.
On peut voir ce problème sur reddit, je vois de temps en temps des messages où l'auteur utilise un retour à la ligne et où ce n'est pas pris en compte.
----------------------------------
Divers jeux : Puissance 4 - Chariot Wars - Sokoban
Ecrivez vos programmes basic sur PC avec BIDE
Breizh_craft
En ligne
Modérateur
Points: 753
Défis: 7
Message
Citer : Posté le 02/01/2018 17:02 | #
Quelle était la raison de son retour à la ligne ? Si c'était pour faire un paragraphe, il aurait dû en faire deux (c'est naturel comme comportement). Sinon, il ne servais à rien.

Les listes ne posent pas de soucis.


Ceci est une liste :
- item
- item
- item


Ce code fait bien des retours à la ligne pour les listes. Normal : le but des langages de markup comme le MD ou le LS, c'est d'être lisible même en texte brut. Pour faciliter l'édition, notamment.
----------------------------------
Informagicien professionnel, prestidigitateur système. Tout est possible.
Ne0tux
Hors ligne
Membre d'honneur
Points: 3113
Défis: 261
Message
Citer : Posté le 02/01/2018 17:10 | #
Coucou,

Je ne comprends pas pourquoi il y a débat. Je vois dans le titre "[pour] la v5", je dis oui !

Discuter en amont c'est productif et nécessaire, mais remettre en question le RFC alors qu'il est près à rouler, ça me parait contre-productif. C'est le 5e draft, c'est Lephenixnoir qui l'a fait, et il prend justement la peine de nous le présenter... Hormis des suggestions je ne vois pas de raison de mettre en cause son choix (je suis pour le libre arbitre des faiseurs !), parce que mon intérêt personnel, c'est de voir la v5 de mon vivant.

Sur le sujet en lui même, je suis heureux d'apprendre ce nouveau langage. J'ai même hâte de pouvoir essayer (je n'utilise pas Reddit, donc je ne connais pas). Mon avis personnel est qu'à partir du moment où il y a des boutons, les membres s'y retrouveront (beaucoup ignorent ce que sont des balises etc). Les plus intéressés, comme nous, apprendront le langage : on parle quand même de quelquechose qui prend environ 120 secondes à maîtriser...

En bref : j'ai une totale confiance en ce que fait Lephenixnoir, qui a probablement plus réfléchi sur le sujet que la plupart d'entre nous. D'autant que si il met à jour ce "mode d'emploi", il n'y a vraiment rien à craindre...
----------------------------------
Mes principaux jeux : Ice Slider - CloneLab - Arkenstone

La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Citer : Posté le 02/01/2018 17:11 | #
La séparation entre deux blocs ne relève pas exactement d'un retour à la ligne parce que le CSS ajustera les marges en fonction. Mais l'idée est légitime, et je veux bien admettre que les retours à la ligne ont du sens (tant pis s'il y a peu d'exemples pour l'illustrer).

Entendons-nous bien : je ne propose pas de les supprimer. Je propose d'utiliser la syntaxe de M↓ pour les insérer.

Je ne surfe probablement pas autant que toi sur Reddit, mais je n'ai pas de souvenir particulier de ce problème. Si ça ne se produit que « de temps en temps », comme tu dis, c'est que les utilisateurs doivent être capables de s'adapter. Enfin passons : cet argument ne porte que sur une application particulière.

Je trouve que pouvoir écrire du code avec le langage est très utile, mais je peux très bien ajouter une option de runtime à l'interpréteur. Plus j'y réfléchis, plus je pense que je vais faire ça.

En gros tant qu'on peut faire des lignes arbitrairement longues dans la <textarea> sur les pages du la v5 je suis d'accord pour implémenter les sauts de lignes « naturels ».

Il me reste deux soucis plus pragmatiques proches de ce sujet :
- Je ne sais pas si le texte dans la boîte de saisie sera en monotypé ou pas (tout petit souci) ;
- Contrairement à ce que Breizh affirme, la définition actuelle du langage ne permet pas définir une liste sans mettre un lien blanche entre la liste et le paragraphe qui précède :

La fin d'un bloc est soit marquée explicitement par la syntaxe (comme les citations qui se terminent toutes par >>>), soit marquée par une ligne vide. C'est important !

Un paragraphe a le droit de commencer par une espace, par contre il doit se terminer par une ligne blanche.

Honnêtement, c'est un problème de trucs chiants à parser. Je peux concevoir un parser qui sait faire ça. Ce sera chiant mais c'est possible. En revanche il y aura des conflits partout. Par exemple il deviendra impossible d'écrire une ligne qui commence par une étoile, un tiret ou un plus. (À moins d'instaurer des règles d'indentation intelligente ou définir les listes non par leur indentation mais par le texte des puces. C'est encore possible.)

C'est vous qui voyez après. La définition actuelle tente de parer au plus simple. Aviez-vous vu qu'il pouvait y avoir un conflit entre les références aux objets de Planète Casio et le smiley :p ? Des trucs comme ça, il y en a à peu près partout, donc j'ai visé pas trop compliqué.
----------------------------------
Rise.
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Citer : Posté le 02/01/2018 17:44 | # | Fichier joint
Je me permets de rajouter quelque chose que j'ai dit à Zezombye tout à l'heure, mais qui mérite probablement d'être partagé ici, sur nos intentions pour la v5 en général. C'est une réponse à l'argument des utilisateurs confus.

----------------------------------
Rise.
Cakeisalie5
Hors ligne
Membre de CreativeCalc
Points: 1604
Défis: 10
Message
Citer : Posté le 02/01/2018 17:58 | #
Lephenixnoir a écrit :
Les spoilers sont gros, vraiment pas très jolis, et utilisés de travers. D'abord, il n'y a pas grand-chose à spoiler sur un forum de programmation. Ensuite, trop de gens les utilisent pour structurer leurs messages ou, plus notablement, descriptions de programmes. Résultat, quand on charge la page il ne s'affiche rien (que des boîtes rouges avec des labels). Alors même que la description du gameplay et les contrôles à utiliser sont plus importants que tout le reste ! Les titres sont plus appropriés pour structurer. Les grandes images seront redimensionnées automatiquement, donc je ne vois pas de raison d'utiliser des spoilers. J'ai pu en rater.

Peut-être que tu trouves qu'ils sont mal utilisés aujourd'hui, mais ils sont un moyen fondamental d'expression à mon sens (l'accueil positif des CW sur Mastodon m'en convainc). Au lieu de voir les spoilers comme un moyen de structurer son document, vois-les comme la possibilité cacher une information derrière une action volontaire de l'utilisateur, à savoir un clic. Les informations sensibles, ou pouvant encenser un conflit, voire tout ce qui est « secret » (e.g. des solutions), n'ont aucun autre moyen de ne pas être exposées directement à l'utilisateur (sauf si, contrairement au Markdown, tu n'élimines pas les multiples lignes vides, et encore, ça dépend encore des dimensions de l'écran du spectateur, donc ça ne constitue pas un moyen valable à mon sens).

Lephenixnoir a écrit :
Le soulignement et le texte barré sont rarement utilisés. Le gras remplit efficacement le rôle de mise en avant prévu par le soulignement, et comme Lightscript ne précise pas ce que <strong> donne comme formatage, on peut aussi opter pour italique/soulignement sans gras. Le texte barré est difficile à lire. Honnêtement, j'ai surtout éliminé ces deux-là pour des raisons de syntaxe. J'ai eu trop de mal à trouver des moyens honnêtes de les introduire dans la définition du langage.

Monsieur Bayart sur Mastodon, ainsi que d'autres, m'ont convaincu du bien fondé de cette remarque :
- le gras sert à mettre en évidence hors-contexte ;
- l'italique sert à mettre en évidence dans le contexte ;
- le fait de souligner, sur le web, est surtout (quasi-exclusivement) la marque d'un lien hypertexte, et ne devrait pas être utilisé pour autre chose. (sur papier, c'est un équivalent de mettre en gras, puisque mettre en gras au stylo ça n'est pas pratique)

À une exception près tout de même : le fait de barrer (parfois combiné au fait de souligner) permet d'indiquer les révisions lors d'une modification. Par exemple, on peut indiquer une progression en barrant progressivement de la TODO list (au lieu d'enlever au fur et à mesure, et donc de forcer les utilisateurs à suivre chaque évolution).

Lephenixnoir a écrit :
Les liens vers une page de profil et les barres de progression étaient compliqués à intégrer à la syntaxe, mais je peux réfléchir au premier avec la syntaxe réservée, par exemple :uLephenixnoir. Le second n'a à ma connaissance jamais été utilisé de façon productive, à part pour poster des commentaires de programmes qui balançaient un chiffre au lieu de donner des éléments intéressants sur l'état de développement des projets. On s'en passera sans peine, je pense.

Sans peine, je ne dis pas, mais il le faudra : c'est la responsabilité du site de garder des URL similaires, sinon rétrocompatibles ! Le principe de cette balise est de fournir un lien valide « même si le lien derrière change », ce qui va contre cette responsabilité.

Zezombye a écrit :
Le remplacement du BBcode est une très mauvaise idée selon moi (s'il est remplacé, vu que je n'ai pas vu d'indication contraire). Etant donné que la quasi-totalité des forums utilisent du BBcode, les utilisateurs y sont habitués, et changer ça pour le markdown (que je n'ai rencontré que sur reddit, personnellement) entraînera de la confusion.

Le markdown est déjà utilisé dans pas mal d'endroits, notamment sur des gros sites type StackOverflow, ou par un nombre croissant d'auteurs.
Et de toute façon, l'argument me semble inadapté ici puisque le « BBcode de Planète Casio » est différent du BBcode « standard » : pas mal de choses manquent, dont les listes.

Zezombye a écrit :
Franchement je suis contre l'enlèvement du BBcode, ça oblige les utilisateurs à apprendre une nouvelle syntaxe dont ils ne se serviront que sur ce forum. Après je pense que rien n'empêche les 2 de coexister (comme c'est le cas avec les backticks actuellement).

Je suis pour le fait de garder les deux langages, au moins dans un premier temps (mais éventuellement d'encourager le lightscript pour les nouveaux messages), afin de pouvoir faire la migration sans soucis et avec les utilisateurs.

Lephenixnoir a écrit :
Zezombye a écrit :
De toute façon il faudra des boutons pour le markdown, vu que c'est inconnu à la plupart des utilisateurs.

Laisse-moi en douter plus que fortement.

Ça dépend fortement de la vision que tu as de ton public. Les gens qui passent, contrairement à ce que tu crois, ne sont pas tous informaticiens : certains pourront même vivre leur première expérience dans une communauté sur Internet ici.

Breizh_craft a écrit :
Quelle était la raison de son retour à la ligne ? Si c'était pour faire un paragraphe, il aurait dû en faire deux (c'est naturel comme comportement). Sinon, il ne servais à rien.

Les listes ne posent pas de soucis.


Ceci est une liste :
- item
- item
- item


Ce code fait bien des retours à la ligne pour les listes. Normal : le but des langages de markup comme le MD ou le LS, c'est d'être lisible même en texte brut. Pour faciliter l'édition, notamment.

En fait… non. En markdown, il faut un espacement entre ce qu'il y a avant la liste et le premier élément de la liste. De rien.

Ne0tux a écrit :
Discuter en amont c'est productif et nécessaire, mais remettre en question le RFC alors qu'il est près à rouler, ça me parait contre-productif. C'est le 5e draft, c'est Lephenixnoir qui l'a fait, et il prend justement la peine de nous le présenter... Hormis des suggestions je ne vois pas de raison de mettre en cause son choix (je suis pour le libre arbitre des faiseurs !), parce que mon intérêt personnel, c'est de voir la v5 de mon vivant.

Ceux qui interviennent ici sont informaticiens, et sont donc au courant que « Code is Law », tout ce qui contrôle ce qui est dit et son formattage participe à diriger la façon dont on penser sur le forum (c'est le cadre du site qui se réflète sur ce qui s'y dit). Twitter est entre autres également critiqué pour ça : le fait que les messages y soient courts privilégient les punchlines et autres coups bas plutôt que des discussions argumentées, réfléchies, voire même attentionnées.

Je ne suis pas contre le « roll first, correct after », loin de là, à condition que cette posture soit assumée par son auteur, ce qui n'est clairement pas le cas ici (l'auteur demande explicitement des commentaires). Après, ce n'est pas la façon de faire la plus courante ici, donc ça ne plaîrait sans doute pas à certains qui s'empresseraient de traiter ça de dictatorial, mais bon.
----------------------------------
Promotion ordinaire sur les inscriptions sur Planète Casio : en ce moment, c'est gratuit !
Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Citer : Posté le 02/01/2018 18:19 | #
Au lieu de voir les spoilers comme un moyen de structurer son document, vois-les comme la possibilité cacher une information derrière une action volontaire de l'utilisateur, à savoir un clic.

Ce n'est pas moi qui tiens à les voir comme un outil de structure alors qu'ils n'en sont pas. Tels qu'ils sont utilisés actuellement, ils ont un effet néfaste et de très rares utilisations productives. Soit tu décides d'ignorer les usages problématiques, mais alors tu ignores sans réponse mes arguments (et donc je vais pas être d'accord, évidemment), soit tu acceptes qu'il faut un effort pour corriger ces comportements.

Pour parler franchement, je n'ai aucune intention de perdre mon temps à modérer les innombrables spoilers utilisés de travers sur Planète Casio. Si vous les voulez, alors vous vous engagez aussi à travailler pour corriger leur usage. Ou alors, encore une fois, vous tournez le dos au problème que j'expose.

Et ce n'est pas un truc superficiel. La page de BIDE en est le témoin : les spoilers permettent à Zezombye de coller une quantité impressionnante de texte sur une seule page au lieu de se faire un wiki propre et bien organisé. Je pourrais aussi coller l'API complète de gint sur le topic. Il y a des gens qui font ça pour leurs bibliothèques.

Pour être très honnête, encore une fois, je pense tellement productif de supprimer pour une durée indéfinie les spoilers afin d'inciter aux bons comportements en termes de structure que l'inconvénient de recourir à des liens externes pour masquer les 10 spoils annuels qui se produisent sur le forum me paraît complètement anecdotique.

Les informations sensibles, ou pouvant encenser un conflit, voire tout ce qui est « secret » (e.g. des solutions), n'ont aucun autre moyen de ne pas être exposées directement à l'utilisateur.

Je suis assez tatillon en termes de théorie ; ça me gêne s'il y a des textes qu'on ne peut pas écrire avec le langage parce que des bouts qu'on veut afficher se retrouvent interprétés en syntaxe, par exemple. Mais là, c'est une question de pratique versus une question de pratique : les ratios d'utilité s'appliquent dans mon esprit.

Par exemple, on peut indiquer une progression en barrant progressivement de la TODO list

On a des issues trackers, des fichiers de Changelog, et si vraiment le besoin absolu se présente, tu peux très bien laisser les points que tu as implémentés en-dessous d'un titre « Choses déjà faites » en plus du titre de ta liste « Choses à faire ». J'ajouterai que le texte barré est significativement plus difficile à lire. À bien réfléchir donc, je ne crois pas que ce soit tellement attirant d'utiliser le barré pour une TODO list sur le forum. Il peut y avoir d'autres exemples par contre, je n'ai pas pensé à tout...

Je suis pour le fait de garder les deux langages, au moins dans un premier temps (mais éventuellement d'encourager le lightscript pour les nouveaux messages), afin de pouvoir faire la migration sans soucis et avec les utilisateurs.

À mon avis ce qui va se passer si l'on fait ça (et qu'on met le Lightscript par défaut sur la v5), c'est que :

– Les nouveaux utilisateurs vont prendre ce qu'on leur donne, possiblement sans remarquer qu'ils ont le choix
– Les membres qui sont ouverts à l'utilisation du LS vont l'utiliser
– Ceux qui seront contre vont continuer à utiliser le BBCode tout le temps

Et quand on voudra supprimer définitivement le BBCode, les membres mécontents vont poser exactement le même problème qu'aujourd'hui. Ça m'étonnerait beaucoup qu'il y a une classe d'utilisateurs plus que négligeable qui utilise les deux langages pendant la potentielle période de transition.

Les gens qui passent, contrairement à ce que tu crois, ne sont pas tous informaticiens : certains pourront même vivre leur première expérience dans une communauté sur Internet ici.

Si c'est leur première expérience, ils n'auront pas de problème à oublier le BBCode...

En fait… non. En markdown, il faut un espacement entre ce qu'il y a avant la liste et le premier élément de la liste. De rien.

Je dois admettre que ça m'arrangerait pas mal si le LS n'avait pas besoin d'autoriser ça. Comme je l'ai dit, ça pose pas mal de problèmes niveau implémentation.

Concernant ta dernière remarque et le « Code is Law » ; je tiens trop à nos membres pour risquer de faire n'importe quoi avec la v5. Mais j'avoue que j'aimerais que les discussions soient plus simples.
----------------------------------
Rise.
Cakeisalie5
Hors ligne
Membre de CreativeCalc
Points: 1604
Défis: 10
Message
Citer : Posté le 02/01/2018 18:45 | #
Lephenixnoir a écrit :
Et quand on voudra supprimer définitivement le BBCode, les membres mécontents vont poser exactement le même problème qu'aujourd'hui. Ça m'étonnerait beaucoup qu'il y a une classe d'utilisateurs plus que négligeable qui utilise les deux langages pendant la potentielle période de transition.

À ceci près qu'il y aura davantage de personnes (on l'espère) qui utiliseront le LS, et pourront donc encourager les autres à l'utiliser plutôt que de ronchonner voire partir. La pression sociale utilisée dans le bon sens

Lephenixnoir a écrit :
Concernant ta dernière remarque et le « Code is Law » ; je tiens trop à nos membres pour risquer de faire n'importe quoi avec la v5. Mais j'avoue que j'aimerais que les discussions soient plus simples.

Pour que ce soit plus simple, il faudrait que tout le monde soit d'accord avec toi d'office.

Après, « imposer » dans un premier temps c'est pas un problème hein, du moment qu'on fait le SAV pour corriger après coup si on voit qu'à l'usage c'est intenable. Rien n'est parfait, mais ça ne signifie pas qu'on ne peut pas s'en rapprocher, sans pour autant attendre que ça ne soit parfait avant de le sortir (oui je sais, je peux parler)

---

Pour le reste, je laisse les autres répondre et enrichir le débat avec des compromis
----------------------------------
Promotion ordinaire sur les inscriptions sur Planète Casio : en ce moment, c'est gratuit !
Besoin d'utilitaires de transfert vers et depuis la calculatrice sous GNU/Linux ?
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Citer : Posté le 02/01/2018 18:53 | #
La pression sociale utilisée dans le bon sens

Ça peut toujours se finir comme ça, mais ça m'enchante pas d'implémenter des trucs legacy dans la v5... faudra porter ton textout en Python en plus.

Pour que ce soit plus simple, il faudrait que tout le monde soit d'accord avec toi d'office.

Je n'irai pas jusque-là. Tu ne t'en rends peut-être pas compte, mais c'est extrêmement fastidieux. Il faut avoir de la motivation pour persévérer quand le premier commentaire qu'on a c'est (rien contre toi ZZ ) :

Le remplacement du BBcode est une très mauvaise idée selon moi

Tu te souviens des heures que ça nous a pris pour nous accorder sur les modalités des nouveaux concours, right? On n'était que trois. Quand on a brainstormé les premiers la v5 avec Darks, le M↓ s'est imposé comme une évidence. J'ai ensuite proposé de le raffiner pour spécialiser les objets au site. Je pense que si t'avais été là ça serait passé facilement aussi (aux détails près).

Maintenant imagine-toi qu'un point aussi simple à traiter pour nous trois engendre de telles discussions sur le forum juste à cause du nombre. Tu penses que ça va se passer comment quand on va annoncer les trucs sur lesquels on a galéré à se mettre d'accord ? x)

'Fin bon. Retour au sujet, j'imagine. C'est les limites du consensus après tout.
----------------------------------
Rise.
Ne0tux
Hors ligne
Membre d'honneur
Points: 3113
Défis: 261
Message
Citer : Posté le 02/01/2018 19:08 | #
Cakeisalie5 a écrit :
Ceux qui interviennent ici sont informaticiens, et sont donc au courant que « Code is Law », tout ce qui contrôle ce qui est dit et son formattage participe à diriger la façon dont on penser sur le forum (c'est le cadre du site qui se réflète sur ce qui s'y dit). Twitter est entre autres également critiqué pour ça : le fait que les messages y soient courts privilégient les punchlines et autres coups bas plutôt que des discussions argumentées, réfléchies, voire même attentionnées.


C'est vrai, et pertinent sur ce topic, mais hors-sujet par rapport à ce que j'ai écrit, tu voulais probablement citer quelqu'un d'autre que moi avant ce paragraphe.

Cakeisalie5 a écrit :
Je ne suis pas contre le « roll first, correct after », loin de là


Donc nous sommes d'accord.

Cakeisalie5 a écrit :
à condition que cette posture soit assumée par son auteur, ce qui n'est clairement pas le cas ici (l'auteur demande explicitement des commentaires)


"Clairement pas" ? Tiens donc ? Il m'a pourtant semblé qu'il avait fait 5 drafts avant de créer ce topic...

Ce n'est certainement pas parce que Lephenixnoir a sollicité l'oeil critique de la communauté qu'il est opposé au "roll first, correct after", c'est une erreur de logique (même si le résultat peut être vrai). Je sens aussi que tu as mal lu mon message : je n'ai rien contre les suggestions concernant ce qu'a déjà fait Lephenixnoir, je l'ai écrit très clairement, comme il est clair en effet que c'est ce qui motivait la création de son topic. C'est la remise en cause du choix de RFC qui me parait contre-productive.

Lephenixnoir a écrit :
Il faut avoir de la motivation pour persévérer quand le premier commentaire qu'on a c'est (rien contre toi ZZ ) : [...]


Voilà qui illustre parfaitement.

Cakeisalie5 a écrit :
Après, ce n'est pas la façon de faire la plus courante ici


Justement. Si on veut aspirer à du renouveau, il est peut-être temps d'arrêter de faire "de la façon la plus courante ici". Pour moi, quand on a confiance en ses partenaires, on discute avant le lancement et/ou on remercie pour leurs prises de décision à la fin (sauf quand le résultat n'est pas là). Rien n'empêche de faire des suggestions en cours de route, comme ici, ou de valider sur demande, mais ça doit être modéré et ne pas entraver la progression vers l'objectif final.

Cakeisalie5 a écrit :
ça ne plaîrait sans doute pas à certains qui s'empresseraient de traiter ça de dictatorial


"Dictatorial" ? Je n'ai pas vu quelqu'un hurler au despote... Et puis je plains les personnes qui se sentent tyrannisées par si peu, elles doivent avoir une vie très frustrante...

Je me demande si ce qui manque ce n'est pas justement un "leader" (ou "dictateur", son pendant côté obscur) pour la v5. Ou bien il faut accepter que les faiseurs soient pleinement compétents et qu'ils aient toute liberté d'agir et de prendre des décisions (en consultant si besoin ponctuellement mais efficacement la communauté).
----------------------------------
Mes principaux jeux : Ice Slider - CloneLab - Arkenstone

La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Citer : Posté le 02/01/2018 19:13 | #
Pour moi, quand on a confiance en ses partenaires, on discute avant le lancement et/ou on remercie pour leurs prises de décision à la fin (sauf quand le résultat n'est pas là). Rien n'empêche de faire des suggestions en cours de route, comme ici, ou de valider sur demande, mais ça doit être modéré et ne pas entraver la progression vers l'objectif final.

Je suis entièrement en phase avec ton propos Ne0', mais je tiens à préciser qu'on est avant le lancement. Mes implémentations des drafts précédents étaient mauvaises ; je suis en train de reprendre de zéro (et c'est la cinquième fois que je le fais).

C'est pour éviter une implémentation inutile supplémentaire, au cas où la spec' se révèle mal écrite, que je sollicite ces commentaires. Techniquement donc, de mon point de vue en tous cas, on est sur une discussion avant lancement. On est presque en train de lancer, mais pas encore.

Du reste, je préfère résoudre les problèmes et éventuels désaccords maintenant parce que le coût d'un « correct after » est plus conséquent que celui d'un changement au moment de la conception. Je peux lister des points qui remettraient en cause une grande partie de l'implémentation s'ils déviaient de ce qui est actuellement proposé.

Ajouté le 02/01/2018 à 20:57 :
Après réflexion, je pense pouvoir proposer des spoilers satisfaisant toutes les exigences évoquées dans les discussions précédentes. En gros :


Niveau implémentation, j'ai triché. HTML5 possède en fait des spoilers nativement à l'aide de deux éléments <details> et <summary>. Cependant ces deux éléments sont du flow content, donc en gros, ce sont des divisions. On ne peut pas les mettre en plein milieu d'un paragraphe, sinon ça ferme automatiquement le paragraphe.

Le fiddle est ici, et comme vous pouvez le voir, j'ai utilisés des <span> mais pas de <p> ; sinon, ça n'aurait pas marché : https://jsfiddle.net/9f537aL6/

Ce spoiler semble satisfaisant car d'une part il remplit son rôle de masquer les informations sensibles, et d'autre part comme il est contenu dans un paragraphe il peut pas lui-même contenir plus d'un paragraphe de texte. Ce qui le rend inapproprié pour structurer un document, au profit des titres et autres wikis.

Concernant les « grandes images », elles seront redimensionnées automatiquement avec un lien automatique si c'est nécessaire, donc pas de problème à attendre de ce point de vue-là.

Je vais réfléchir à ce que je peux faire pour préserver l'aspect strict du « spoiler contenu dans un paragraphe » tout en restant compatible avec l'implémentation qu'en fait HTML5. Ça va peut-être changer un peu le résultat.
----------------------------------
Rise.
Dark storm
Hors ligne
Administrateur
Points: 10319
Défis: 174
Message
Citer : Posté le 05/01/2018 05:45 | #
Juste, qu'on soit d'accord, les références aux objets internes du site (topic, commentaire, programme, etc.) s'utilisent de cette manière ?

[lien vers le topic 352](:f352) // lien inline
[lien vers le programme 1234][prog] // lien via une référence

[prog]: :p1234
----------------------------------
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Páranÿe quetë Quendya
Lephenixnoir
Hors ligne
Administrateur
Points: 11627
Défis: 136
Message
Citer : Posté le 05/01/2018 09:27 | #
Actuellement ; pas du tout :

Le topic :f352 répond à la question posée ; le programme :p1234 la met en application.


<p>Le topic <a href='.../forum/352'>Usage simultané de <code>""</code> et <code>Locate</code> ?</a> répond à la question posée : le programme <a href='.../prog/1234'>Paper Mario 2019</a> la met en application.</p>

Edit : Mais c'est une idée très intéressante et ça m'a l'air tout à fait faisable.
----------------------------------
Rise.

Pages: 1, 2, 3, 4 | Suivante

Index du Forum > Vie communautaire > Le langage de forum de la v5 - Lightscript (RFC)

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2018 | Il y a 43 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire indépendant, géré bénévolement et n'est donc pas affilié à Casio | Toute reproduction de Planète Casio, même partielle, est interdite
Les fichiers, programmes et autres publications présents sur Planète Casio restent la propriété de leurs auteurs respectifs et peuvent être soumis à des licences ou des copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd