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.
The [[[/]]] generic block marker was suggested for those cases.
{.spoiler}
[[[
This is a paragraph
And this is another
]]]
1 Like
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.
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.
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.
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.
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 
(especially if we will run this in browser via javascript)
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}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.
+++ 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
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
+++ 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
Hence my preference for ! over @ for generic directives, since it is already used for links.
e.g. !youtube[ cat ]( df7d8f8w3f )
It depends how long the spoiler blocks are. The use cases that I have seen are generally no more than a few paragraphs, so explicitly defining each paragraph isn’t painful. But I see that you also take issue with regular Markdown blockquotes, so criticism is best directed at that decision first.
The approach of reusing the block quote syntax for spoilers is appealing. My main concern is using an English word such as “spoiler” to define this block which does not internationalise well. Spoiler blocks are common on discussion platforms and are likely used by non-English speakers. The Stack Exchange spoiler syntax >! handles this by using an exclamation mark instead of an English word.
Yes. Blockquote container works nice, if you have 1-2 paragraphs. All examples with blockquotes are of this type. But since we are discussing standard, we have to cover all cases, or declare that other cases are out of interest. I’d like to avoid sitiuation, when blockquote is promoted as universal solution. Because it isn’t. With big blocks it’s horible both for typing and for reading.
Thanks! As far as i see, requests for alternate block container are floating for a long time. It would be nice, if those will not became suppressed by blockquote extentions.
Spans are required too, but in worst case those can be hacked via AST with some luck. Blocks can’t be hacked in safe manner, and require good support at parse phase. I think, we have everything to declare those without pain. Fenced blocks are investigated and covered very well. We need only to invent alternate marker and declare “parseable fenced blocks”
+++ Vitaly Puzrin [Oct 30 14 02:11 ]:
Blocks can’t be hacked in safe manner, and require good support at parse phase. I think, we have everything to declare those without pain. Fenced blocks are investigated and covered very well. We need only to invent alternate marker and declare “parseable fenced blocks”
I’m not yet sold on the idea that these should be fenced blocks, as opposed to side-marked (whether by overloading blockquotes, or by introducing another side marker).
You raise the issue of long blocks. But there is also a problem with fences for long blocks, which is that it’s easy to lose track of the fact that you’re in a special kind of section. With side-marking, there is a constant reminder of the scope of the section.
In addition, with fences, as Fletcher Penny pointed out on the markdown-discuss group, deleting one line can radically change the meaning of huge parts of the document. Side-marking is more “local.”
I think the biggest argument for fenced code blocks (when we originally introduced them on the markdown-discuss list) was that indented code blocks are inconvenient for cutting and pasting code (either from a program to the markdown document, or in the reverse direction). That consideration doesn’t apply as much to generic block containers. Generic block containers do seem to me to be a generalization of blockquotes. So, using side-marking for them seems more in the spirit of Markdown than introducing fences. It would be more consistent with the rest of the syntax.
It is interesting to compare the main competitors, AsciiDoc and reSructuredText. AsciiDoc uses fences:
[NOTE]
.A NOTE admonition block
=====================================================================
Qui in magna commodo, est labitur dolorum an. Est ne magna primis
adolescens.
. Fusce euismod commodo velit.
. Vivamus fringilla mi eu lacus.
.. Fusce euismod commodo velit.
.. Vivamus fringilla mi eu lacus.
. Donec eget arcu bibendum
nunc consequat lobortis.
=====================================================================
reStructuredText uses indentation to determine the scope of the block container:
.. note:: This is a note admonition.
This is the second line of the first paragraph.
- The note contains all indented body elements
following.
- It includes this bullet list.
Interestingly, in both cases the method used aligns with the approach to blockquotes. In AsciiDoc blockquotes are fenced; in reStructuredText they are indented blocks. (It may be that you prefer the AsciiDoc approach…but then, why not just use AsciiDoc?)
The main complaints that have been raised against blockquote-style syntax are (a) that it is a pain to write and (b) that it is hard to read. I see why one might worry about these things, but (a) is completely solved if you use a decent text editor, and I’m just not sure that the difference in readability (b) is all that great. As I pointed out above, the presence of the side markers reminds you that you’re in a special section, which you might otherwise lose track of in a longer section, so there’s a way in which it increases readability. (In a published book special sections are often put in a box with a different background color or font.)
I’m not at all decided on this issue; I’m just explaining why I don’t find it an easy one.
1 Like
It’s also worth considering using indentation to mark the scope of the container. That also has good Markdown pedigree, since that is how we deal with list items. Indeed, we could re-use the list item rules.
.NOTE
This is a note admonition.
This is the second line.
- A list.
- Another item.
Next paragraph, not in the note.
1 Like
I’m not so sure. For example, I often wrap notes and half-finished snippets in my markdown documents in a <div class="note"></div> and then move that text (including lists and blockquotes) out of the div as I finalize it.
That’s indeed the major downside of fenced blocks. However, would you have lazy continuation for those blocks as well? Then the visual cue is radically reduced. I think we have to face the reality that a lot of people aren’t using a decent text editor—that’s why lazy continuation is so popular. And honestly, I write a lot of markdown in iA Writer as well, just because I find that its beautiful typography and environment puts me in a different mind-set than when I’m coding. And then yes, when I need to format a blockquote I quickly switch to vim and copy’n’paste it back. And let’s not talk about some environments that use non-monospaced fonts (ahem, Discourse, ahem). Working with block-based indentation when using soft-line-wraps (as most people do when not working with code) becomes quickly a mess as well.
When working in normal/non-code/non-decent editors, I find fiddling with side-markers/indentation a lot more challenging than using fences. That being said, I think both fenced and side-marked blocks are workable solutions.
:::::::::::: SPOILER :::::::::::::
Spoiler Text Here etc....
::::::::::::::::::::::::::::::::::
converts to
<div class="spoiler" >
<div class="key header" > spoiler </div>
... content here...
</div>
http://talk.commonmark.org/t/content-block-inline-syntax/815