What could a "spoiler tag" extension look like?

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

21

IMHO block spoilers are for big texts, when secondary level of content is much bigger than primary one and you wish to visually balance result. It would be inconvenient to manuall type many “>” when you wish to wrap a big pease of article.

22

The [[[/]]] generic block marker was suggested for those cases.


{.spoiler}
[[[
This is a paragraph

And this is another
]]]
1 Like
23

The syntax for spoiler block quotes is already implemented on Stack Exchange, maybe collision issues can be overcome? Or were you referring to inline spoilers? Maybe the >! syntax could be used just for block spoilers.

24

I don’t like it. We have different goals. They wish to hide visibility. I wish to save vertical size - that requires header for collapsed states and easy wrapping for long multiparagraph text. >! does not fit any of those requirements.

May be, for SE goals >! will be ok. For my ones - not.

25

For multi-paragraph spoilers, I would expect them to work the same as regular block quotes. You would only need to add >! at the start of each paragraph. I see what you mean about headers though, the Stack Exchange syntax does not support spoiler headers and it is not clear how it could.

26

Are you serious? That’s not user friendly to manually patch text. Normal solution is something like fenced blocks. We discussed that in block syntax thread. >! for blocks is inconvenient, and need additional kludges for headers. IMHO, that’s movement to wrong direction.

27

On extra thought. I would like to express opposition to implementing this syntax. This is because spoilers is often done as a CSS style under .spoiler.

It’s much easier to just use:

[ Spoiler Text Here]{ .spoiler }

I do not believe that internationalizing spoiler tags is an issue, since it is possible to have a list of recommended css names. For other languages, just document it’s spelling of spoiler classname, so that it can be included in international sites.

To avoid this becoming like ASCII doc, we really need to keep the specs syntax as minimum as possible and avoid putting in syntax that would work just as well as a css class or as a directive. (Directives is here to help keep core syntax small btw)

On the argument that >! !< feels more like markdown. I would say, having a low initial learning curve is also ‘markdown’. From simple rules can come complexity and flexibility. Much like how RISC eventually became the go to choice over CISC instruction sets in CPU.

Oh, and it helps keeps parser small and fast :smiley: (especially if we will run this in browser via javascript)

28

I’m not at all in favor of adding (even as an extension) something as specific as “spoilers.”

We already have an element that can contain arbitrary block-level content: block quotes. And we already have an element that can contain arbitrary literal content: code blocks.

Providing a way to add attributes to these, and a mechanism for intercepting these attributes in a writer module and doing something special with them, would provide enough flexibility to implement many kinds of special features, including call-out blocks and declarative images.

A simple way to add attributes would be using a special type identifier on the line before the block:

 .WARNING
 > Be careful of the following:
 >
 > 1. Extra spaces at the ends of lines.
 > 2. Files that do not end with a newline.

 .DOT
     digraph finite_state_machine {
             rankdir=LR;
             size="8,5"
             node [shape = doublecircle]; LR_0 LR_3 LR_4 LR_8;
             node [shape = circle];
             LR_0 -> LR_2 [ label = "SS(B)" ];
             LR_0 -> LR_1 [ label = "SS(S)" ];
             LR_1 -> LR_3 [ label = "S($end)" ];
             LR_2 -> LR_6 [ label = "SS(b)" ];
             LR_2 -> LR_5 [ label = "SS(a)" ];
             LR_2 -> LR_4 [ label = "S(A)" ];
             LR_5 -> LR_7 [ label = "S(b)" ];
             LR_5 -> LR_5 [ label = "S(a)" ];
             LR_6 -> LR_6 [ label = "S(b)" ];
             LR_6 -> LR_5 [ label = "S(a)" ];
             LR_7 -> LR_8 [ label = "S(b)" ];
             LR_7 -> LR_5 [ label = "S(a)" ];
             LR_8 -> LR_6 [ label = "S(b)" ];
             LR_8 -> LR_5a [ label = "S(a)" ];

By default, the first example could be rendered as a div with class “WARNING”, the second as a code block with class “DOT”. But an easy mechanism could be provided to users to modify renderers to handle these sections in different ways. For example, a docbook renderer could render a block container of type WARNING as a <warning> element, and a latex renderer could use a special “warning” environment. Similarly, an HTML renderer could render a block container of type DOT by running dot -Tpng on the contents and including a data URI with the contents of the generated image, while a LaTeX renderer could render it using dot -Tpdf and including the resulting PDF.

Perhaps a list of key-value attributes could be allowed after the type identifier. Indeed, an alternative would be to use the attribute syntax in pandoc and some other implementations: {.class #id key="value" key="value"}. But these braces make the text look more like a computer program than it needs to.

Of course, it may also be desirable to allow attributes to be added to inline content and inline literals in the same way. Here, perhaps, braces are necessary:

 [this is some *inline* content]{color=blue lang=en}

 `x >>= y`{language=haskell}
29

IMHO, blockquotes are not user friently about formatting. These requires too many changes to wrap big text. And looks broken on long auto-wrapped lines, if window size reduced. I have feeling, that blockquotes are deffective by design, and we fall into repair broken things with kludges. Probably, that’s historical issues - 10 years ago it was enougth for simple things.

I’d like to have simple way to mark start and end of block, like fences do. In theory, we could make subparser call for fences with special param. But it’s too hacky for standard.

30

+++ Vitaly Puzrin [Oct 28 14 20:30 ]:

IMHO, blockquotes are not user friently about formatting. These requires too many changes to wrap big text. And looks broken on long auto-wrapped lines, if window size reduced. I have feeling, that blockquotes are deffective by design, and we fall into repair broken things with kludges. Probably, that’s historical issues - 10 years ago it was enougth for simple things.

I’d like to have simple way to mark start and end of block, like fences do. In theory, we could make subparser call for fences with special param. But it’s too hacky for standard.

There’s a rather long thread about this in pandoc-discuss from last year. Nothing really got settled, but a lot of considerations were raised, so it might be valuable to look at it.

2 Likes
31

Indeed, as proposed in the generic attributes thread, I like that syntax as well: it is basically a span element. It would be nice to have a corresponding div syntax. Using block quotes feels semantically wrong, and sometimes you might want the containing blocks to be parsed as well.

@jgm do you feel that the proposed directives are “overkill”?

1 Like
32

+++ Mb21 [Oct 29 14 13:46 ]:

@jgm do you feel that the proposed directives are “overkill”?

I like the flexibility, but it looks too “codish” in my opinion. (I also worry about overusing the @ character: it is widely used now in usernames, and also in citations in pandoc markdown.)

My suggestion was motivated by the desire to have something that was more naturally readable, but offering the same flexibility.

1 Like