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