La mise en spoiler de parties de deux paragraphes ne fonctionne pas correctement

En mode Markdown, tapez ceci :

A B

C D

Sélectionnez B et C, mais pas A et D, puis « Flouter le spoiler ».

Le résultat ressemblera à ceci :

A [spoiler]
B

C
[/spoiler] D

Et le résultat ne sera pas flouté par le spoiler.

A [spoiler]
B

C
[/spoiler] D

Essayez à nouveau en mode texte enrichi. Commencez par ceci :

A B

C D

Sélectionnez B et C et floutez le spoiler.

La rupture de paragraphe sera supprimée et le résultat ressemblera à ceci :

A BC D

Si vous revenez en mode Markdown, le résultat ressemblera à ceci :

A [spoiler]BC[/spoiler] D
1 « J'aime »

À quel résultat vous attendriez-vous dans ce cas, étant donné que le spoiler ne peut pas être à la fois en ligne et en bloc ?

Je pense que l’idée qu’un spoiler ne puisse pas être à la fois en ligne et en bloc est un fait du CSS dont l’utilisateur n’a pas besoin d’être informé.

Contexte : Comment le HTML gère-t-il cela ?

Considérez le gras. Vous pouvez écrire ceci en bbcode Discourse aujourd’hui :

A [b]B

C[/b] D

Ou vous pouvez écrire ceci en HTML :

<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</p>

<p>C</strong> D</p>
</body>
</html>

Cela s’affiche exactement comme vous vous y attendez :

A B

C D

Mais la représentation du DOM ressemble à ceci :

<p>A <strong>B</strong></p>
<p>
<strong> </strong>
<p><strong>C</strong> D</p>

La spécification HTML exige que quelque chose de similaire se produise pour les hyperliens multi-blocs. Si vous écrivez ceci en HTML :

<!DOCTYPE html>
<html>
<body>
<p>A <a href="https://example.com.">B</p>

<p>C</a> D</p>
</body>
</html>

La spécification HTML exige que la représentation du DOM ressemble à ceci, avec trois hyperliens :

<body>
<p>A <a href="https://example.com.">B</a>
</p><a href="https://example.com."> </a>
<p><a href="https://example.com.">C</a> D</p>
</body>

Ma proposition : Spoilers liés

Vous pourriez imaginer rendre les spoilers en ligne multi-paragraphes de manière similaire :

<p>A <spoiler>B</spoiler></p>

<p><spoiler>C</spoiler> D</p>

Mais les spoilers sont différents du gras, car les spoilers sont interactifs. Lorsque vous cliquez sur la partie B du spoiler, elle est censée révéler les parties B et C du spoiler ; elle est censée ressembler et donner l’impression d’être “un seul spoiler”.

Je pense que la façon de gérer cela est de prendre en charge les spoilers liés dans la représentation du DOM. Peut-être que <spoiler> aurait un attribut comme name, et lorsque vous cliquez sur un spoiler, il révélerait tous les spoilers portant le même nom. (Faut-il le faire avec des attributs, des propriétés ou un autre système pour lier les trois spoilers ? Je ne sais pas, faites-le comme vous voulez.)

Alors, supposez que vous ayez du Markdown comme ceci :

A B

C

D E

[spoiler]F[/spoiler]

Et que vous sélectionnez B, C et D et que vous les floutez.
Le Markdown ressemblerait alors à ceci :

A [spoiler]B

C

D[/spoiler] E

[spoiler]F[/spoiler]

Et le DOM généré ressemblerait à ceci :

<p>A <inline-spoiler name="x">B</inline-spoiler></p>

<block-spoiler name="x"><p>C</p></block-spoiler>

<p><inline-spoiler name="x">D</inline-spoiler> E</p>

<block-spoiler name="y"><p>F</p></block-spoiler>

En JS, lorsque vous cliquez sur l’un des trois spoilers, tous les spoilers portant le même attribut “name” se révèlent ensemble.

Ainsi, du point de vue de l’utilisateur final, cela donnerait l’impression que vous pourriez mélanger et assortir des spoilers en ligne et en bloc.

J’ai déplacé ceci de Bug vers Feature car la fonctionnalité que nous explorons actuellement n’est pas prise en charge.

@dfabulich Pourriez-vous partager le cas d’utilisation que vous cherchez à prendre en charge ? Cela nous aidera à comprendre la meilleure façon d’aborder une solution. Pouvez-vous nous dire à quel point le support de cette forme de spoilers en ligne + bloc serait utile dans votre communauté, ou quand ils surviennent ?

Je pense que c’est une mauvaise idée de qualifier cela de « fonctionnalité ».

Je pourrais imaginer dire « ce bug est trop difficile à corriger ; il n’est pas logique de lui donner la priorité sur d’autres travaux ».

Mais je ne pense pas que quiconque défendrait le comportement actuel comme étant correct.

Quant à votre question, il n’est pas vraiment possible de donner un « cas d’utilisation » pour la correction d’un bug. Les fonctionnalités ont des cas d’utilisation (Masquer les spoilers : les utilisateurs veulent masquer les spoilers afin de pouvoir discuter de médias sans gâcher la surprise), mais les bugs résident à l’intérieur des fonctionnalités. Corriger les bugs est la façon dont une fonctionnalité remplit son cas d’utilisation.

Pourquoi ce bug est-il important ? Parce que nous utilisons beaucoup les spoilers !

Si je traite ce problème comme un « bug », et que je reconnais que la mise en œuvre de ma solution proposée pourrait être coûteuse, le plus près que je puisse faire pour répondre à votre question sur le « cas d’utilisation » est de répondre à une autre question :

« Pourquoi ce bug est-il important ? En admettant que le comportement actuel est incorrect, qui se soucie du fait que vous ne pouvez pas masquer du texte en ligne sur plusieurs paragraphes ? Avez-vous vraiment besoin de faire cela ? »

Et à cela, je pense que je dirais : l’expérience actuelle est juste confuse et mine la confiance de l’utilisateur dans Discourse. Lorsque vous sélectionnez du texte et que vous cliquez sur Masquer le spoiler et que cela ne masque tout simplement pas le texte que vous avez sélectionné, c’est tout simplement embarrassant pour toutes les personnes impliquées.

Honnêtement, ce serait une amélioration modeste par rapport au comportement actuel d’afficher un message d’erreur lorsqu’un utilisateur tente de masquer des parties de deux paragraphes, en informant l’utilisateur de la nature du problème. Le message d’erreur pourrait dire : « Dans Discourse, vous pouvez masquer une partie d’un paragraphe, ou vous pouvez masquer un ou plusieurs paragraphes entiers, mais vous ne pouvez pas créer un spoiler contenant des parties de deux paragraphes ou plus. »

Mais imaginez maintenant si vous deviez afficher un tel message d’erreur pour du texte en gras ? Ou en italique ?

Et cela explique pourquoi les spoilers sont importants pour moi : le forum que j’exploite (et d’autres forums Discourse auxquels je participe) sont des forums de joueurs, où parler de médias, et surtout sans gâcher les solutions aux énigmes, est une affaire très importante.

Je peux comprendre pourquoi quelqu’un dirait « Le masquage des spoilers n’est pas aussi important que le texte en gras. Nous corrigerons le bug pour le gras en créant plusieurs sections en gras, mais pour le masquage des spoilers, nous avons juste des problèmes plus importants à régler ; laissons le bug des spoilers non corrigé. Nous ne nous soucions pas tellement des spoilers. Les utilisateurs trouveront une solution de contournement. »

Mais pour moi et mon forum, et les forums sur lesquels je vis, le masquage des spoilers est marginalement plus important que le texte en gras. C’est pourquoi je me suis concentré sur ces bugs de masquage des spoilers !

Quel est le « cas d’utilisation ? » Le cas d’utilisation est : nous utilisons les spoilers pour parler de médias sans gâcher la surprise. Et donc, la fonctionnalité de masquage des spoilers devrait fonctionner, et fonctionner correctement, pour satisfaire ce besoin.

1 « J'aime »

Pour ma part, je pense qu’il y a un bug et une fonctionnalité ici. Nous pouvons être en désaccord sur la sémantique, mais je tiens à expliquer comment nous envisageons cela afin que vous compreniez la suite, étant donné l’importance des spoilers pour vous et votre communauté.

Le bug est que lorsque vous essayez d’appliquer un spoiler en ligne et sur plusieurs blocs, les sauts de paragraphe sont supprimés (en mode texte enrichi) et ajoutés (en mode Markdown) :

Texte enrichi :

Markdown :

Je suis d’accord que ce n’est pas une expérience agréable. Nous pouvons corriger ce bug, mais cela se traduira soit par :

  • Deux spoilers distincts, l’un sur chaque ligne, qui devront être cliqués séparément pour être révélés.
  • Un seul spoiler, mais le contenu sélectionné sera forcé dans son propre bloc.

La demande de fonctionnalité est de prendre en charge un seul spoiler qui peut commencer en ligne et s’étendre sur plusieurs blocs, puis être révélé en un seul clic. Ce n’est pas ainsi que les spoilers sont censés fonctionner.

La raison pour laquelle je vous ai interrogé sur votre cas d’utilisation est d’aider à corriger le bug et à comprendre l’importance de la fonctionnalité. Nous voyons généralement les spoilers soit en ligne, soit sous forme de blocs, je me demande donc s’il existe des situations particulières où le spoiler en ligne + bloc entre en jeu. Cela nous aide à mieux comprendre comment vous utilisez Discourse et à comprendre comment la résolution de ce problème pourrait vous aider (ainsi que d’autres qui reconnaissent les besoins de leur propre communauté dans ce que vous partagez ici).

1 « J'aime »

Compte tenu de ces deux options, je pense que je choisirais « Un seul spoiler, mais le contenu sélectionné sera forcé dans son propre bloc. »

Je ne peux pas vraiment donner de raison basée sur un cas d’utilisation ; je pense que le comportement de bloc forcé serait toujours bogué.

Mais l’option de bloc forcé me semble « moins boguée » car elle n’affecte que l’apparence du spoiler : ajout d’un saut de ligne supplémentaire au début et à la fin du spoiler.

Avoir plusieurs spoilers non liés affecte le fonctionnement du spoiler. Les lecteurs devraient cliquer jusqu’à trois fois pour révéler l’intégralité du spoiler : une fois pour le spoiler en ligne principal, puis à nouveau pour N spoilers de bloc, puis à nouveau pour le spoiler en ligne final.

Avec les spoilers à bloc forcé, cela devient un bug matériel cosmétique, le genre de chose sur lequel personne ne travaillera jamais.

2 « J'aime »

Ce cadrage a du sens pour moi :

Nous allons travailler à corriger cela ; je n’ai pas de date d’échéance à vous communiquer, mais je mettrai à jour ici une fois que nous aurons résolu ce problème.

1 « J'aime »