What could a "spoiler tag" extension look like?

Extensions
61

There are no need to blindly follow abstract principles, if it cost nothing to satisfy more people in shorter time by swapping order of 2 steps. I’ve explained above, that 1/2 of DIV spec (for fenced style) needs very few work for acceptance.

May be i have wrong estimate about efforts. But at least, nobody said the opposite.

I would do it, but it’s not acceptable. @chrisalley, i’m not going to push anyone for making fast decisions. I just share info, to better plan my own work. Because if alternatives possible, i’ll select one, which is better for CommonMark.

1 Like
62

Comment about how div is still needed for practicality, even if we seek for mostly semantic tag. Moved to Content Block/Inline Syntax

1 Like
63

IMHO you mix completely different things. You explain that “fenced container” not needed, because it can be replaced by several things, that not exists now but will be available sometime :slight_smile: .

  1. Those are needed anyway, it’s a question of usability and preferences. For example, i don’t need lyrics, but i don’t say that line blocks are useless.
  2. Fenced blocks can be accepted faster, that other. I never said, that those are better or more important. I said, that now we have no containers at all with full attributes support, and it worth to accept at least one type. Then i explained, that acceptance of fenced block is the most easy in terms of time and efforts, not because i like those.
1 Like
64

There are quite a few different proposals being made here which has complicated the discussion.

I’ve outlined why there’s an issue with fenced blocks being used for <div>'s (very applicable to the use case of spoilers).

That leaves line blocks and blockquotes, which have proposals for both side-marking and proposals for fenced block styles.

Line blocks that are side marked are a natural extension of sidemarked blockquotes which are already in the spec. It seems likely that sidemarked line blocks will become an extension.

Given this likelihood, if fenced blockquotes and line blocks are added they would be in addition to the sidemarked blocks, and so may not be needed if sidemarked blocks are sufficient.

The question (I think) @jgm was asking is why either sidemarked blockquotes or lineblocks are unusable in their current state? I suggested that it would be good to see some real world examples of the sidemarking syntax creating problems for the writer. Examples of actual text, rather than lists of features.

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.

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 GitHub - github/markup: Determines which markup library to use to render a content file (e.g. README) on GitHub (see, eg, [Feature Request] Spoiler support in comments (eg for PGP signature "compression") · Issue #411 · github/markup · GitHub)

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

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