In Markdown mode, type this:
A B
C D
Select B and C but not A and D, then “Blur spoiler.”
The result will look like this:
A [spoiler]
B
C
[/spoiler] D
And the result will not be spoiler-blurred.
A [spoiler]
BC
[/spoiler] D
Now try it again in rich-text mode. Start with this:
A B
C D
Select B and C and spoiler blur.
The paragraph break will be deleted, and the result looks like this:
A BC D
If you switch back to Markdown mode, the result looks like this:
A [spoiler]BC[/spoiler] D
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.
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>
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.
I’ve moved this from Bug → Feature since what we’re exploring here is currently unsupported functionality.
@dfabulich Could you share the use case that you’re looking to support? That will help us understand how to best to approach a solution. Can you tell us about how supporting this form of inline + block spoilers would be useful in your community, or when those come up?
I think it’s the wrong call to categorize this as a “feature.”
I could imagine saying “this bug is too hard to fix; it doesn’t make sense to prioritize it over other work.”
But I don’t think anybody would defend the current behavior as correct.
As for your question, it’s not really possible to give a “use case” for a bug fix. Features have use cases (Blur Spoiler: Users want to blur spoilers so they can discuss media without ruining the surprise), but bugs reside inside features. Fixing the bugs is how a feature fulfills its use case.
If I treat this issue as a “bug,” and acknowledge that implementing my proposed solution might be expensive, the closest I can get to answering your “use case” question is to answer a different question:
“Why does this bug matter? Granting that the current behavior is incorrect, who cares that you can’t blur inline text across multiple paragraphs? Do you even really need to do that?”
And to that, I think I’d say: the current experience is just confusing, and undermines the user’s trust in Discourse. When you select some text and click Blur Spoiler and it simply doesn’t blur the text you selected, it’s just embarrassing for everyone involved.
Honestly, it would be a mild improvement over the current behavior to display an error message when a use tries to spoilerize parts of two paragraphs, educating the user about the nature of the problem. The error message could say: “In Discourse, you can spoilerize part of one paragraph, or you can spoilerize one or more entire paragraphs, but you can’t make a spoiler containing parts of two or more paragraphs.”
But now imagine if you had to show an error like that for bold text? Or italic?
And that gets to why spoilers matter to me: the forum I operate (and other Discourse forums I participate in) are gamer forums, where talking about media, and especially without spoiling the solutions to puzzles, is a really big deal.
I can understand why someone would say “Spoiler blur isn’t as important as bold text. We’ll fix the bug for bold by making multiple bold sections, but for spoiler blur, we’ve just got bigger fish to fry; let’s leave the spoiler bug unfixed. We just don’t care about spoilers that much. Users will find a workaround.”
But for me and my forum, and the forums I live on, spoiler blur is marginally more important than bold text. That’s why I’ve been pushing on these spoiler blur bugs!
What’s the “use case?” The use case is: we use spoilers to talk about media without ruining surprise. And so, the blur spoiler feature should work, and work correctly, to satisfy that need.
For my part, I think there’s a bug and a feature here. We can disagree on semantics but I do want to explain how we’re looking at this so you understand what comes next here, given how important spoilers are to you and your community.
The bug is that when you try to apply a spoiler inline and across blocks, the paragraph breaks are removed (in rich text mode) and added to (in Markdown mode):
Rich text:
Markdown:
I agree this isn’t a pleasant experience. We can fix that bug, but what that will look like is either:
The feature request is to support a single spoiler that can start inline and span multiple blocks, and then be revealed with a single click. That is not how spoilers were designed to work.
The reason I’ve asked about your use case is to assist with both fixing the bug and understanding the importance of the feature. We typically see spoilers either inline or as blocks, so I’m wondering if there are particular situations where the inline + block spoiler comes into play. That helps us get to know how you use Discourse better and understand how solving this could help you (and others who recognize their own community’s needs in what you share here).
Given those two options, I think I’d pick “A single spoiler, but the selected content will be forced into its own block.”
I can’t really give a use-case based reason for this; I think the forced-block behavior would still be buggy.
But the forced-block option feels “less buggy” to me because it “only” affects how the spoiler looks: adding an extra line break at the beginning and end of the spoiler.
Having multiple unlinked spoilers affects how the spoiler works. Readers would have to click as many as three times to reveal the entire spoiler: once for the leading inline spoiler, then again for N block spoilers, and then again in the trailing inline spoiler.
With forced-block spoilers, it becomes a cosmetic Hard Bug, the sort of thing that maybe nobody will ever work on.
