Good point. That might be the reason why Stack Exchange put > at the start of the line. I’m just guessing though. It would be worth finding out if there is an actual conflict.
Btw, the >! syntax looks like it’s saying: Quote… stop!
1 Like
I see what you mean.
Still, I think all of these still feel quite unnecessary. Take for instance how others dealt with it in reddit:
[Spoiler](/s "write spoiler-text inside quotes")
used in
- http://www.reddit.com/r/asoiaf/comments/i2mg6/attention_we_now_have_a_new_spoilertagging_system/
- http://www.reddit.com/r/anime/comments/r9rfx/new_spoiler_code_and_some_stuff_about_convention/
[Pikachu won](#spoiler)
used in
This shows that !spoiler[ Pikachu won ] is better for general usage, since it is equivalent to the pokemon example that uses the well known []() structure. Plus reduces cruft in core syntax. (Plus you avoid the weirdness with html comments tags)
1 Like
I appreciate the point about reducing cruft from the core syntax. The main reason why I like the Stack Exchange syntax (>! or some close variant) is because it feels like Markdown. The examples you listed introduce English language into the syntax, which is quite un-Markdown like. That’s a very subjective reason, I know. An objective reason to avoid English words in the syntax is because it internationalises better.
This is not to put down the directive syntax, but I see the directives as more of an advanced feature. It seems the need to add a spoiler is relatively common in a forum discussion which is a justification for spoilers having their own syntax.
1 Like
If > can be handled for blockquotes, would >! for block spoilers be any more of a problem?
1 Like
How do you tell if ! is part of a quote rather than part of a spoiler text?
>! this is not a spoiler
> but rather a weirdly written quote.
Aside from that, I don’t see any issue with it, and while I’m against increasing the core syntax. I think this can be acceptable. But do wonder if it would work to keep it as an 'extended syntax, enabled for certain layouts or site settings (e.g. layout=wiki ). Or is it used so often that it really should be added to core. Because I’m not convinced that it is used in 80% of use case.
I think a good philosophy on what should go into core syntax is 80% common broad base usage.
1 Like
Good point. The spec says that blockquotes may be “a single character > not followed by a space” so this could indeed be a problem.
My suggestion would be to make the space a requirement if you’re starting the quote text with a !, otherwise it will be interpreted as a spoiler.
I agree that spoilers should be an extension. Note @codinghorror’s comment in this post about fenced code blocks intentionally being the only significant addition to the core. It seems unlikely that any of the major additions we’ve been discussing will be accepted as part of the core and that’s fine.
2 Likes
Well, that’s why I would like to see:
- Document Declaration - to declare what extentions to core via syntax extensions or directives is expected (via commonmark flavours)
- 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
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?
-
>>" ??? "<< -
>># ??? #<< -
>>( ??? )<< -
>>{ ??? }<< -
>>[ ??? ]<< -
>>| ??? |<< -
>>% ??? %<<
Some applications:
>>" Text To Speech transcriptions? Might be useful. "<<
I’d just use an inline attribute
*spoiler text here*{: .spoiler}
And
> spoiler text
> multiline
{: .spoiler}
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
It would be worth checking if there is actually an issue for the parser with the >! syntax.
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 !<
IMHO:
- 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.
- As noticed above
>!will cause serious collisions with blockquotes. May be something like!>spoiler<!
1 Like
{.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.
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.