Het spoileren van delen van twee alinea's werkt niet goed

Typ in Markdown-modus:

A B

C D

Selecteer B en C, maar niet A en D, en klik vervolgens op “Spoiler vervagen”.
Het resultaat ziet er als volgt uit:

A [spoiler]
B

C
[/spoiler] D

En het resultaat wordt niet vervaagd door de spoiler.

A [spoiler]
B

C
[/spoiler] D

Probeer het nu opnieuw in de rich-textmodus. Begin met dit:

A B

C D

Selecteer B en C en vervaag de spoiler.
De paragraafonderbreking wordt verwijderd en het resultaat ziet er als volgt uit:

A BC D

Als je terugschakelt naar de Markdown-modus, ziet het resultaat er als volgt uit:

A [spoiler]BC[/spoiler] D
1 like

What result would you expect in this case, considering the spoiler can’t be both inline and block?

I think the idea that a spoiler can’t be both inline and block is a fact of CSS that the user shouldn’t need to be made aware of.

Background: How does HTML handle it?

Consider bolding. You can write this in Discourse bbcode today:

A [b]B

C[/b] D

Or you can write this in HTML:

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

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

It renders exactly the way you’d expect it to render:

A B

C D

But the DOM representation looks like this:

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

The HTML spec calls for something similar to happen for multi-block hyperlinks. If you write this in HTML:

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

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

The HTML spec calls for the DOM representation to look like this, with three hyperlinks:

<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>

My proposal: Linked spoilers

You could imagine rendering multi-paragraph inline spoilers in a similar way:

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

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

But spoilers are different from bold, because spoilers are interactive. When you click on the B part of the spoiler, it’s supposed to reveal both the B and the C part of the spoiler; it’s supposed to look and feel like “one spoiler.”

I think the way to handle this is to support linked spoilers in the DOM representation. Perhaps <spoiler> would have an attribute like name, and when you click on a spoiler, it would reveal all spoilers with the same name. (Should this be done with attributes, properties, or some other system for linking the three spoilers? I dunno, do it any way you like.)

So, suppose you’ve got Markdown like this:

A B

C

D E

[spoiler]F[/spoiler]

And you select B, C, and D and blur them.

The Markdown would then look like this:

A [spoiler]B

C

D[/spoiler] E

[spoiler]F[/spoiler]

And the generated DOM would look like this:

<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>

In JS, when you click on any one of the three spoilers, all spoilers with the same “name” attribute would reveal themselves together.

Thus, from the end-user’s perspective it would feel like you could mix’n’match inline and block spoilers.

Ik heb dit verplaatst van Bug naar Feature, aangezien wat we hier onderzoeken momenteel niet-ondersteunde functionaliteit is.

@dfabulich Zou je de use case kunnen delen die je wilt ondersteunen? Dat helpt ons te begrijpen hoe we een oplossing het beste kunnen benaderen. Kun je ons vertellen hoe het ondersteunen van dit soort inline + block spoilers nuttig zou zijn in jouw community, of wanneer deze zich voordoen?

Ik denk dat het verkeerd is om dit als een “functie” te bestempelen.

Ik zou kunnen zeggen: “deze bug is te moeilijk om op te lossen; het heeft geen zin om het voorrang te geven op ander werk.”

Maar ik denk niet dat iemand het huidige gedrag zou verdedigen als correct.

Wat betreft je vraag, het is niet echt mogelijk om een “use case” te geven voor een bugfix. Functies hebben use cases (Blur Spoiler: Gebruikers willen spoilers vervagen, zodat ze media kunnen bespreken zonder de verrassing te verpesten), maar bugs bevinden zich binnen functies. Het repareren van de bugs is hoe een functie aan zijn use case voldoet.

Waarom is deze bug belangrijk? Omdat we veel spoilers gebruiken!

Als ik dit probleem als een “bug” behandel en erken dat het implementeren van mijn voorgestelde oplossing duur kan zijn, is het dichtstbijzijnde wat ik kan doen om je “use case” vraag te beantwoorden, een andere vraag te beantwoorden:

“Waarom is deze bug belangrijk? Gegeven dat het huidige gedrag onjuist is, wie geeft erom dat je geen inline tekst over meerdere paragrafen kunt vervagen? Heb je dat echt nodig?”

En daarop denk ik dat ik zou zeggen: de huidige ervaring is gewoon verwarrend en ondermijnt het vertrouwen van de gebruiker in Discourse. Wanneer je tekst selecteert en op Blur Spoiler klikt en het de geselecteerde tekst simpelweg niet vervaagt, is dat gênant voor alle betrokkenen.

Eerlijk gezegd zou het een kleine verbetering zijn ten opzichte van het huidige gedrag om een foutmelding weer te geven wanneer een gebruiker delen van twee paragrafen wil spoilen, waardoor de gebruiker wordt geïnformeerd over de aard van het probleem. De foutmelding zou kunnen zeggen: “In Discourse kun je een deel van één paragraaf spoilen, of je kunt één of meer volledige paragrafen spoilen, maar je kunt geen spoiler maken die delen van twee of meer paragrafen bevat.”

Maar stel je nu eens voor dat je zo’n foutmelding zou moeten tonen voor vetgedrukte tekst? Of cursief?

En dat brengt ons bij waarom spoilers voor mij belangrijk zijn: het forum dat ik beheer (en andere Discourse-forums waar ik aan deelneem) zijn gamer forums, waar het praten over media, en vooral zonder de oplossingen van puzzels te verklappen, erg belangrijk is.

Ik kan begrijpen waarom iemand zou zeggen: “Spoilervervaging is niet zo belangrijk als vetgedrukte tekst. We zullen de bug voor vetgedrukte tekst repareren door meerdere vetgedrukte secties te maken, maar voor spoilervervaging hebben we gewoon grotere vissen te bakken; laten we de spoilerbug onopgelost laten. We geven gewoon niet zoveel om spoilers. Gebruikers zullen een oplossing vinden.”

Maar voor mij en mijn forum, en de forums waar ik op leef, is spoilervervaging marginaal belangrijker dan vetgedrukte tekst. Daarom heb ik me gericht op deze spoilervervagingsbugs!

Wat is de “use case?” De use case is: we gebruiken spoilers om over media te praten zonder de verrassing te verpesten. En dus moet de blur spoiler-functie werken, en correct werken, om aan die behoefte te voldoen.

1 like

Wat mij betreft is er hier sprake van een bug en een feature. We kunnen het oneens zijn over de semantiek, maar ik wil graag uitleggen hoe we hiernaar kijken, zodat u begrijpt wat hierna komt, gezien het belang van spoilers voor u en uw community.

De bug is dat wanneer u probeert een spoiler inline en over blokken toe te passen, de paragraafafbrekingen worden verwijderd (in de rich text-modus) en toegevoegd (in de Markdown-modus):

Rich text:

Markdown:

Ik ben het ermee eens dat dit geen prettige ervaring is. We kunnen die bug oplossen, maar dat zal er als volgt uitzien:

  • Twee aparte spoilers, één op elke regel, die afzonderlijk moeten worden aangeklikt om te onthullen
  • Een enkele spoiler, maar de geselecteerde inhoud wordt gedwongen in zijn eigen blok

Het featureverzoek is om een enkele spoiler te ondersteunen die inline kan beginnen en meerdere blokken kan overspannen, en vervolgens met één klik kan worden onthuld. Zo zijn spoilers niet ontworpen om te werken.

De reden dat ik naar uw use case heb gevraagd, is om te helpen bij het oplossen van de bug en het begrijpen van het belang van de feature. We zien doorgaans spoilers die ofwel inline ofwel als blokken zijn, dus ik vraag me af of er specifieke situaties zijn waarin de inline + block spoiler van toepassing is. Dat helpt ons om beter te begrijpen hoe u Discourse gebruikt en hoe het oplossen hiervan u (en anderen die de behoeften van hun eigen community herkennen in wat u hier deelt) kan helpen.

1 like

Gezien die twee opties, denk ik dat ik zou kiezen voor “Een enkele spoiler, maar de geselecteerde inhoud wordt in zijn eigen blok geforceerd.”

Ik kan hier geen use-case gebaseerde reden voor geven; Ik denk dat het geforceerde blokgedrag nog steeds buggy zou zijn.

Maar de geforceerde blokoptie voelt voor mij “minder buggy” omdat het alleen van invloed is op hoe de spoiler eruitziet: het toevoegen van een extra regeleinde aan het begin en einde van de spoiler.

Meerdere niet-gekoppelde spoilers beïnvloeden hoe de spoiler werkt. Lezers zouden wel drie keer moeten klikken om de hele spoiler te onthullen: één keer voor de leidende inline spoiler, dan nog een keer voor N blok spoilers, en dan nog een keer in de afsluitende inline spoiler.

Met geforceerde blok spoilers wordt het een cosmetische Hard Bug, het soort ding waar misschien nooit aan gewerkt zal worden.

2 likes

This framing does make sense to me:

We will work on fixing that up; I don’t have an ETA for you but I will update here once we’ve addressed this.

1 like