What could a "spoiler tag" extension look like?

Extensions
#65

Let’s clarify. DIV is HTML term. We are speaking about block containers, not divs. Term DIV was used with meaning “block element with markup content”. Representation depends on renderer. For example, spoiler can be rendered to several nested divs. Other containers can be rendered to articles, sections, asides and anything else.

Probably, i missunderstood you, because your replied to my post. None of listed examples can be now expressed with sidemarking, because the only existing container (blockquote) in current state do not support attributes. That’s the root of problem. I would agree to use sidemarking as temporary solution, if attributes are supported. But i don’t believe, that it’s possible to add attributes support in reasonable time.

There are no reasons to say, that one type of block is better than another one. That depends on content type, size, editor and user preference. Even in this thread >1 users prefer sidemarking and >1 users prefer fencing.

1 Like
#66

Forgive me for bumbling in but I really want this feature now that me and my team have a use case for it.

I’m assuming that because the discussion has shifted from ‘what should the markdown look-like to users’ to ‘how many div tags should we use and by the way what exactly is a div tag anyways’ that this issue has been sort’ve accepted. But the last post on this issue is from last year and I’m not sure where it would move forward. Any news?

The use case I’ve got is, on github, my team now reads and votes on issues before sprint kickoff. Right now those votes are just plaintext as comments, so if you’re voting as a junior dev and a senior dev has already voted you cant help but be biased by glancing at the comments. I’d like to put the votes in spoiler tags so that a reader has to have an explicit intent to see the vote. I noticed that stackoverflow was already doing this with a scheme that was perfect for my use case, but github was not.

Again, for this use case, the >! syntax is pretty good. It might get a little terse if vote-commenters simply do

>! 3

instead of

>! my vote is 3 points

but terse comments aren’t really markdowns fault (or problem).

Alternatively this could be a feature request with github. A reasonably elegant work-around would be to leverage the systems typically put in to reduce spam. If Github supported a ‘flag this comment’, which hid the comment (a le youtube or stack overflow), I could leverage that system to achieve this goal.

my .02, hope this happens soon!

#67

>! probably would work neatly and the nice thing of it is that a diff-view extension would fit as well as
>+ and >-.

a spoiler can still be implemented attaching the css class to a normal blockquote.

>
>  Fooo
>
{: class}
#68

+++ Groostav [Apr 23 15 21:00 ]:

I’m assuming that because the discussion has shifted from ‘what should the markdown look-like to users’ to ‘how many div tags should we use and by the way what exactly is a div tag anyways’ that this issue has been sort’ve accepted. But the last post on this issue is from last year and I’m not sure where it would move forward. Any news?

No proposal has been accepted.

The use case I’ve got is, on github, my team now reads and votes on issues before sprint kickoff. Right now those votes are just plaintext as comments, so if you’re voting as a junior dev and a senior dev has already voted you cant help but be biased by glancing at the comments. I’d like to put the votes in spoiler tags so that a reader has to have an explicit intent to see the vote. I noticed that stackoverflow was already doing this with a scheme that was perfect for my use case, but github was not.

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.

If you’re asking how one might achieve this with a setup that used a CommonMark parser, then it seems to me that you could achieve what you want without any syntax changes at all, by establishing conventions.

For example, you could establish the convention that any block quote beginning with a single ! will be treated as a spoiler. On the server, you’d then walk the AST after parsing, looking for blockquotes that fit this description, and inserting some raw HTML around them to make them display hidden by default, with a button to display them.

No fancy block attribute syntax is needed for this, and there are some advantages to NOT using a fancy block attribute syntax (your document will degrade nicely on github or another Markdown renderer). Note also that, even if there were a fancy block attribute syntax, you’d still have to do some custom processing of the AST. Although we might consider generic block attribute syntax, “spoiler” seems far too specialized a thing to be part of the spec.

Support for alert/warning boxes
Generic directives/plugins syntax
#69

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.

#70

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.

#71

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

#72

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

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-----
::::::::::::::::::::::::::
__________________________
#74

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

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Fenced Block Types, Generic Extension/Webcomponents, and fallback handling
#75

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

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

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

Did this change since 2011?

The magic link target seems to vary:

1 Like
#78

Sorry, should have linked it!

These spoiler tags are part of the release notes.

#79

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.

#80

@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
#81

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>
#82 
> 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
#83

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

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.

2 Likes