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}