What could a "spoiler tag" extension look like?

My tendency is to encourage these sorts of requests to be markdown post-processors.

Consider that

>!

produces

<blockquote>
    <p>!</p>
</blockquote>

and that

>! example

produces

<blockquote>
    <p>! example</p>
</blockquote>

a post-processor can simply look for blockquote > p:first-child and test that the text begins with ! to apply spoiler markup.

The advantage to post-processors is that they can be easily configured to suit individual needs. Want to change the spoiler class? Use a config option. Want to change the wrapping code? Use a config option.

I think this would be better suited to a small webapp which connects to GitHub’s API. The app would list the project’s issues and allow one vote for each GitHub account with access to the project. Maybe an app like this already exists? Edit: Maybe this would do the job.

I also want a spoiler tag, but for a different reason. I’d like to be able
to pgp-sign “looks good to merge” messages. Those messages should otherwise
be a few words, but instead look like a huge mangle of text. Spoiler
message would be a nice way to hide the mess while still making it
available for those who want it.

This is, in fact, the reason I joined this list :).

I’m a bit unclear about what you’re looking for. If you’re trying to do this on github, then only changes to github’s Markdown processor will help you, and this isn’t the right place to be asking.

Actually, github has been referring people here when they ask on https://github.com/github/markup (see, eg, https://github.com/github/markup/issues/411)

1 Like

I see so github admins is waiting for commonmark to implement this first. Interesting that it would be used to keep gpg keys hidden.


If custom containers looks like:

::: warning :::
dragon is here
:::::::::::::::

then a block spoiler could perhaps look like below ( dingus view (Seems to degrade gracefully too) ) :

__________________________
::::::::::::::::::::::::::
    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: 2.6.i

    mQCNAi+UeBsAAAEEAMP0kXU75GQdzwwlMiwZBUKFUDRgR4wH9y5NP9JaZfVX8shT
    ESbCTbGSEExB2ktEPh5//dkfftsKNlzlAugKFKTgBv20tQ9lDKfdbPVR0HmTLz0e
    wVIeqEue4+Mt/Kq7kMcQy+5sX2RBAiZTYl0n/JdY/WxflU0taq1kH/UUPkklAAUR
    tB5NYXJ0eSBNY0ZseSA8bWFydHlAZnV0dXJlLmNvbT6JAJUCBRAvlHhGrWQf9RQ+
    SSUBAQX+BACnhx7OTb1SfAcJVF/1kuRPUWuGcl57eZgv4syc1O9T3YNr0terWQBT
    K0vFR00FdaBv9X9XwlxaBJHGeiBcmhaiOTwB912ysoteUzZHne3sHPw3MkYboAFx
    xHg43Cnj60OeZG2PKp/kU91ipOJP1cs8/xYOGkeoAMqDfwPeFlkBiA==
    =ddBN
    -----END PGP PUBLIC KEY BLOCK-----
::::::::::::::::::::::::::
__________________________

Another idea:

Fenced ^ chevron. Which to me, the chevron fenching either looks like it should be cut out, or collapsing on itself.

^^^^^^^^^^^^^ My PGP KEY ^^^^^^^^^^^^^

    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: 2.6.i

    mQCNAi+UeBsAAAEEAMP0kXU75GQdzwwlMiwZBUKFUDRgR4wH9y5NP9JaZfVX8shT
    ESbCTbGSEExB2ktEPh5//dkfftsKNlzlAugKFKTgBv20tQ9lDKfdbPVR0HmTLz0e
    wVIeqEue4+Mt/Kq7kMcQy+5sX2RBAiZTYl0n/JdY/WxflU0taq1kH/UUPkklAAUR
    tB5NYXJ0eSBNY0ZseSA8bWFydHlAZnV0dXJlLmNvbT6JAJUCBRAvlHhGrWQf9RQ+
    SSUBAQX+BACnhx7OTb1SfAcJVF/1kuRPUWuGcl57eZgv4syc1O9T3YNr0terWQBT
    K0vFR00FdaBv9X9XwlxaBJHGeiBcmhaiOTwB912ysoteUzZHne3sHPw3MkYboAFx
    xHg43Cnj60OeZG2PKp/kU91ipOJP1cs8/xYOGkeoAMqDfwPeFlkBiA==
    =ddBN
    -----END PGP PUBLIC KEY BLOCK-----

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Hi, I was linked into this discussion from the github discussion here.

While I can’t say that “markdown definitely needs this extension” in order to succeed on its own terms, it would be extremely useful in a variety of odd-ball usecases for the people who actually use markdown on github and in other places.

The thing is that while spoiler text is a pretty simple idea, it’s very difficult to accomplish satisfactorily using just html in a cross-browser way. Getting a nice effect like Stack Exchange achieves is perfect for many of the one-off usecases that I’ve seen, but creating “a small webapp” every time you want to use it is just not at all an effective use of a person’s time.

The upshot is that making it a part of the standard would add some real value for users, I think, even if it’s just a perk.

If for whatever reason people definitely don’t want spoiler text to become part of the standard, that would also be an okay resolution, since then at least we can go back to github and petition them to use an extension like StackExchange has or create their own extension. (Since they said they are keen to use CommonMark, but spoiler text seems useful enough that if CommonMark definitely won’t standardize it, then it seems plausible that they will add that feature separately.)

1 Like

Looks like reddit implemented this - both inline and blockquote variants!

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

Did this change since 2011?

The magic link target seems to vary:

1 Like

Sorry, should have linked it!

These spoiler tags are part of the release notes.

Discord recently added the ability to put “guardrails” around spoiler text to mark it up. E.g.

The film reveals that ||the bad guy is actually his father||.

Discord uses a flavour of Markdown in chat conversions; the addition of guardrail syntax here makes sense since it represents something. Perhaps it could be extended into block syntax like this:

|||
Big spoiler here.
|||

In any case, an inline spoiler syntax would be useful in chat conversations and comments systems, perhaps even more so than a block spoiler syntax. The Discord inline spoiler syntax is bit easier to remember than the !>spoiler<! syntax proposed earlier as it doesn’t require remembering the specific order of the opening/closing characters, plus the characters feel more meaningful.

@jgm just to put some perspective on this, I’ve been surprised how often spoilers come up in typical internet posts. It may not be big in the Pandoc audience, but I assure you, for more non-techie conversational topics, spoilers come up wayyy more than I ever thought they would. They come up a lot.

I’d still get tables in first, but spoilers is certainly in my top 3 of potential markdown extensions that people actually use and ask for.

Heck you can kinda see that in how pervasive “rolling your own syntax” is for this use case! And it kinda sucks that they’re all over the place, no two sites seem to do it the same way :confused:

3 Likes

Just a thought: could spoilers be treated as a special kind of deleted content <del>?

~foo~
~~bar~~
~~~~baz~~~~
~~~~~~~~quuz~~~~~~~~
.
<sub>foo</sub>
<s>bar</s>
<del>baz</del>
<del class="spoiler">quuz</del>
> If this is a blockquote

>! and this is a block spoiler
[> then this could be an inline quote using `<q>`]

[>! and this could be an inline spoiler.]
2 Likes

Looks good @aoudad. I like the simplicity. Plus it degrades… sort of ok

render: https://spec.commonmark.org/dingus/?text= >%20If%20this%20is%20a%20blockquote >!%20and%20this%20is%20a%20block%20spoiler [>%20then%20this%20could%20be%20an%20inline%20quote%20using%20`<q>`] [>!%20and%20this%20could%20be%20an%20inline%20spoiler.]


For the slightly weird edge case of wanting to hide or shrink the pgp keyblock so it doesn’t take up visual space… Its ok

>! -----BEGIN PGP PUBLIC KEY BLOCK-----
>! Version: 2.6.i
>!
>! mQCNAi+UeBsAAAEEAMP0kXU75GQdzwwlMiwZBUKFUDRgR4wH9y5NP9JaZfVX8shT
>! ESbCTbGSEExB2ktEPh5//dkfftsKNlzlAugKFKTgBv20tQ9lDKfdbPVR0HmTLz0e
>! wVIeqEue4+Mt/Kq7kMcQy+5sX2RBAiZTYl0n/JdY/WxflU0taq1kH/UUPkklAAUR
>! tB5NYXJ0eSBNY0ZseSA8bWFydHlAZnV0dXJlLmNvbT6JAJUCBRAvlHhGrWQf9RQ+
>! SSUBAQX+BACnhx7OTb1SfAcJVF/1kuRPUWuGcl57eZgv4syc1O9T3YNr0terWQBT
>! K0vFR00FdaBv9X9XwlxaBJHGeiBcmhaiOTwB912ysoteUzZHne3sHPw3MkYboAFx
>! xHg43Cnj60OeZG2PKp/kU91ipOJP1cs8/xYOGkeoAMqDfwPeFlkBiA==
>! =ddBN
>! -----END PGP PUBLIC KEY BLOCK-----

Discord have now added support for spoilers, but they are using the ||spoiler|| syntax instead.

I think this really needs standardising.

@aoudad I like the block spoiler there, but the inline one looks weird.

3 Likes

Heads up that reddit is now using this format as a sitewide standard for spoilertext Formatting Guide – Reddit Help

>!spoilers!<

Key thing is they have !< to close off a spoiler. This will be curious to figure out how to work out between inline and block spoilers.

But anyway this is an additional point for >! inclusion in the next standard update.

1 Like

To summit it up we have 3 live versions where two of them is very similar

This make me wonder will it make sense to change the blockqoute standard a little and add a required space after > In that way we could use >! for block spoilers and make it act in the same way as a blockqoute. then we could use >!spoilers!< for inline.

This >!spoilers!< is inline
>! This is a block spoilers 
and it works the same way as blockqoute it can contain other tags inside it.

>! It can also continue just like a normal blockqoute

I personally find it a good solution as the pros and cons are good.

Pros:

  • Big platforms like Reddit and Stack can keep their current solutions.
  • It is a syntax that people are familiar with.
  • It feels like markdown and easy to use as it reminds people of blockqoutes.
  • The syntax of inline and block is familiar.

Corns:

  • We would have to change the blockqoute standard by adding a required space. However the impact of this is very little as it is already good practice and used in most editions.
  • Discord would have to change their syntax, but as most user on the platform doesn’t use markdown when chatting it should not be a bigger problem.

If you’re trying to continue the same spoiler block, I think you’d need additional markup in the empty line:

>! This is a block spoilers 
and it works the same way as blockqoute it can contain other tags inside it.
>!
>! It can also continue just like a normal blockqoute

Not trying to be nitpicky, just pointing out the standard. If you have an empty line, in CM, it will be a break between two quotes, like this:

Stuff 1

Stuff 2

> Stuff 1

> Stuff 2

As opposed to if you do have the extra bracket:

Stuff 1

Continued stuff 1

> Stuff 1
> 
> Continued stuff 1

So, if you’re trying to echo that, you’ll need to have the >! in that line. :slight_smile:

Also, technically, no platform needs to change their standards (provided they’re not in conflict with another usage - so if || was used to denote something else in CM) - you can have customized ones for your own platform - Discord would just need to add the “official” version - not necessarily remove their current one.

Oh! totalt forgot that CM has a different way to handle blockqoutes. But I agree