What could a "spoiler tag" extension look like?

Extensions
1

The Stack Exchange already has a special spoiler markdown tag on its movie/tv/etc. sites that works like this:

>! E.T. phones home!

and outputs a blockquote with the class “spoiler”:

<blockquote class="spoiler">
  <p>E.T. phones home!</p>
</blockquote>

Even though there are some arguments against it, I think that an inline-type spoiler tag might be useful too (especially since on reddit, a lot of subreddits have improvised inline spoiler tags using CSS on links like this: [spoiler text](#spoiler))

In a pull request I made to reddit’s markdown parser Snudown, I thought up what an inline spoiler tag could look like:

This is a sentence >!with a spoiler in it.!<

Which would output:

This is a sentence <span class="spoiler">with a spoiler in it.</span>

Though, I wonder if it would make a line that starts with an inline spoiler trickier to to write a parse for, like:

>!Spoiler at the beginning!< of this sentence

may render like:

<blockquote class="spoiler">
  <p>Spoiler at the beginning!< of this sentence</p>
</blockquote>

instead of:

<span class="spoiler">Spoiler at the beginning</span> of this sentence

sometimes.

Because there’s a nice port of snudown to emscripten, I built it and made a quick test page of my modded snudown based off of the stmd.js test page so people can see this idea in action

https://arresteddevelopment.github.io/spoiler-test/

Would having both an inline-style and a blockquote-style spoiler tag be useful, or would it be less confusing if just one style was picked? I imagine the blockquote style would be best, as it falls back better when text is pasted where spoiler tags aren’t supported

4 Likes
2 
!spoiler[ E.T. phones home! ]

This is a sentence !spoiler[ E.T. phones home! ] with spoiler in the middle

!spoiler
[[[
    This is a
    multiline spoiler text
]]]

!!!spoiler
    This is a
    multiline spoiler text
!!!

(Still debating in my head which generic directive style for block directives is better…)
( Why this, rather than dedicated syntax?: To keep core syntax small. Plus purpose is easily readable.)

1 Like
3

I really like this syntax. It reminds me a lot of the link/image syntax, essentially saying “this links to something (an image), but it is not a regular link”. Similarly, “this quotes something (a spoiler), but it is not a regular quote”.

The use case could be broader and made to mean “hidden quote” so that it could be used for non-spoiler-but-still-hidden quotes.

I am less sure about the inline version, but I can see the use case for it.

4

Alternatively, you could put the ! first, e.g.

!> E.T. phones home!

And for the inline syntax:

This is a sentence !>with a spoiler in it.<!

This might be more consistent with links/images.

3 Likes
5

Furthermore, > could be the directive here, with the above syntax being a shortcut. So any of these could be used:

!>[Click/tap to show spoilers](This is the Spoiler)

!> This is the Spoiler

!> This is the Spoiler <!

1 Like
6

Is there any danger that !> ... <! would conflict with html tags? E.g. comments? (Which is why I think !spoiler[ ... ] is safer )

1 Like
7

Good point. That might be the reason why Stack Exchange put > at the start of the line. I’m just guessing though. It would be worth finding out if there is an actual conflict.

Btw, the >! syntax looks like it’s saying: Quote… stop!

1 Like
8

I see what you mean.

Still, I think all of these still feel quite unnecessary. Take for instance how others dealt with it in reddit:

[Spoiler](/s "write spoiler-text inside quotes")

used in

[Pikachu won](#spoiler)

used in

This shows that !spoiler[ Pikachu won ] is better for general usage, since it is equivalent to the pokemon example that uses the well known []() structure. Plus reduces cruft in core syntax. (Plus you avoid the weirdness with html comments tags)

1 Like
9

I appreciate the point about reducing cruft from the core syntax. The main reason why I like the Stack Exchange syntax (>! or some close variant) is because it feels like Markdown. The examples you listed introduce English language into the syntax, which is quite un-Markdown like. That’s a very subjective reason, I know. An objective reason to avoid English words in the syntax is because it internationalises better.

This is not to put down the directive syntax, but I see the directives as more of an advanced feature. It seems the need to add a spoiler is relatively common in a forum discussion which is a justification for spoilers having their own syntax.

1 Like
10

If > can be handled for blockquotes, would >! for block spoilers be any more of a problem?

1 Like
11

How do you tell if ! is part of a quote rather than part of a spoiler text?

>! this is not a spoiler
> but rather a weirdly written quote.

Aside from that, I don’t see any issue with it, and while I’m against increasing the core syntax. I think this can be acceptable. But do wonder if it would work to keep it as an 'extended syntax, enabled for certain layouts or site settings (e.g. layout=wiki ). Or is it used so often that it really should be added to core. Because I’m not convinced that it is used in 80% of use case.

I think a good philosophy on what should go into core syntax is 80% common broad base usage.

1 Like
12

Good point. The spec says that blockquotes may be “a single character > not followed by a space” so this could indeed be a problem.

My suggestion would be to make the space a requirement if you’re starting the quote text with a !, otherwise it will be interpreted as a spoiler.

I agree that spoilers should be an extension. Note @codinghorror’s comment in this post about fenced code blocks intentionally being the only significant addition to the core. It seems unlikely that any of the major additions we’ve been discussing will be accepted as part of the core and that’s fine.

2 Likes
13

Well, that’s why I would like to see:

  1. Document Declaration - to declare what extentions to core via syntax extensions or directives is expected (via commonmark flavours)
  2. Generic Directives - to solve most use cases that is not common enough to be in core syntax, but is not troublesome enough to be an ‘syntax extension’.

Your idea of space requirement is reasonable, and I think I can accept >! for block spoiler. Not absolutely convinced on safety as an in line spoiler though. Agreed that this should be an extension in a layout or flavour.

1 Like
14

Hmmm… would this work? It should be safer for the parser I think.

>>! Spoiler Text Here D: !<<

While we are at it. Other concepts with this approach. Maybe we can make it do other things?

Here are some that looks good (stuff like $ took too much presence). Any other functions you can think for it?

  1. >>" ??? "<<

  2. >># ??? #<<

  3. >>( ??? )<<

  4. >>{ ??? }<<

  5. >>[ ??? ]<<

  6. >>| ??? |<<

  7. >>% ??? %<<

Some applications:

  1. >>" Text To Speech transcriptions? Might be useful. "<<
15

I’d just use an inline attribute

*spoiler text here*{: .spoiler}

And

> spoiler text
> multiline
{: .spoiler}
16

ah… I forgot we have “consistent attribute syntax”. Yea that would work aright (and better than a generic directive). Though the other reason proposed by another person here is that it’s a bit English specific, and that it is used everywhere enough to have an internationalized version of the spoiler tag.

Btw this is the specific way to use spoiler css class using consistent attributes

inline:

[*spoiler text here*]{.spoiler}

Block:

spoiler block of text here
more text here, etc...
{.spoiler}

> Quoted spoiler block of text here
> more text here, etc...
{.spoiler}
1 Like
17

It would be worth checking if there is actually an issue for the parser with the >! syntax.

18

yea, I hope somebody can answer if >! is an issue for parser. My concern is if you have this:

This is a test text with some spoiler tag using a tag that is bigger ( < ) than >! this is a spoiler !<

or something similar ya know anything like blablabla < bla >! spoiler text !<

19

IMHO:

  1. Mixing spoilers with blockquotes is bad idea.
  • Looks like hack, not consistent with other cases
  • Representation is different. Inline spoilers replace text with rectangle. From block spoilers i expect collapse/uncollapse content + header (use for space save).
  • I think, that block and inline spoilers are completely different things, and it’s normal to have different syntax for these.
  1. As noticed above >! will cause serious collisions with blockquotes. May be something like !>spoiler<!
1 Like
20

{.spoiler} is just a class. you can apply it to normal blocks

{.spoiler}
This is a secret!

Usually I consider spoilers some special blockquotes though.