Do we want the "spoiler" feature turned off?

Question

As I noted in an earlier question on meta, blockquotes starting with a "!" are rendered as spoilers. It happened in this question on the parent site before I edited the post and changed the blockquote to a code block. Here I don't want to talk about when to use which of these two; that's the topic of another question on meta. For those who wonder why I ask a very similar question as in my previous post: The question in that one is effectively locked by the "status-bydesign" tag.

For completeness I repeat the "spoiler" effect here:

! LaTeX Error: File `hypernat.sty' not found.

You see that the text only shows up when the mouse hovers over it, and that the "!" has gone: This is a new feature that "!" introduces a "spoiler". In the above example, the "spoiler" effect clearly is not desired. So I'd like to know if others agree that we want the feature turned off on tex.sx. Personally, I see no reason why we would want this feature.

In the comments to his answer to my earlier question, Kevin Montrose wrote that I

will need a corpus of posts demonstrating that this feature is an actual problem, and not a theoretical one.

He noted himself that I won't find many posts where this is an issue. My point is: I think that the one example I gave is quite sufficient; it took me some time to find out what happened, and is was a "naturally occurring" thing as TeX error messages always start with a "!". And I'm sure it will happen again that users post error messages in blockquotes. I think we don't want our users to learn all the features of the software before they can format and post a decent question, so even if a blockquote isn't optimal for error messages, it's OK for an inexperienced user to use it.

There are two possibilities of turning the feature off:

1. Turn it off completely, so using >! won't cause the paragraph to be marked as "spoiler" class at all.

2. Change only the CSS of our site, so the html still shows that the paragraph is "spoiler" class, but let it be rendered like a usual blockquote. This has the drawback that the "!" gets eaten, but I think that's not a big deal. One will still immediately see that the blockquote is an error message.

What do others think about this?

Answer 1

Apparently the spoiler effect doesn't affect blockquotes that were baked in before the feature came into effect. So, e.g., Sharpie's question, Can MikTeX texmf trees contain the equivalent of a "symbolic link"? has a !-begun blockquote, which renders as a spoiler if you look at the source, but as intended if you don't. Presumably if the question were edited without touching the block quote, the spoiler effect would be activated.

This is the second of 27 search results for "LaTeX Error"; I expect there are a fair few more examples. I think this shows there is a significant reoccurring problem here.

I'm not sure how Kevin balances local convenience against sitewide consistency, but there already is markup variation with respect to rendering maths. We could have a list of markup properties that vary, and put the local settings in the FAQ.

Answer 2

This has been discussed, and is being declined. Let me explain why, exactly.

After doing an exhaustive search (looking at all posts that match >\s*! † anywhere in their entire history) I found that the following posts contain the spoiler syntax.

1. Can MikTeX texmf trees contain the equivalent of a “symbolic link”? (*)
2. An answer to How can I change the legend's location in a pgfplot? (*)
3. “inputenc Error: Unicode char \u8” error while trying to write a degree symbol (invisible character) (*)
4. “TeX capacity exceeded” because of a couple of raiseboxes in a \section…? (*)
5. A revision of MiKTeX 2.9 Does NOT Support `hypernat`

Depending on how you want to count (affected, or potentially affected) this is either 0.01% or 0.07% of all posts to date.

I hope it's clear (and not contentious) that this is a very rare problem.

_{*Posted prior to the spoiler feature being added, so not actually affected, but could potentially be if a non-trivial edit is made (and the editor ignores the preview).}

_{†This would grab everything that even might trigger the spoiler code. The results were then checked by hand to find the true matches.}

---

However, it is still a problem which should be addressed. I'll touch on why the solutions proposed here are unacceptable, and then go into what has actually been done to alleviate it.

Simply turn spoilers off - this would make Tex.SE's markdown syntax (negatively) distinct from every other SE's. Assuming non-trivial cross pollination of users (that is, new users who are familiar with some other SE) this is potentially confusing. Given how rare the "accidental spoiler" problem is, I call this a wash** at best.

Tweak the spoiler CSS - most obviously, posts would still lose ! when they tripped over the spoiler syntax which would just lead to more bug reports. Less obviously, this would be an irreversible change; if spoilers were to become a desired feature (something that can't be discounted, given its popularity as a [feature-request]), we couldn't re-enable it because doing so would retroactively hide text in old posts. Its worth noting that (in supporting browsers) a user can use User CSS to do this client-side.

_{**The only markdown feature not on everywhere is LaTeX rendering (which is on for CSTheory, Math, and Physics). This is because the MathJax library is so large (and cpu intesive) that it has a deleterious effect on page load. It is also "additive" with regards to our baseline markdown, making it less dangerous in my opinion.}

---

Ok, now for what has actually been done to mitigate this (already, vanishingly rare) issue.

At the time of the only truly affected post's creation, the preview pane wasn't rendering spoilers. This could definitely hit TeX harder than other sites, and upon discovering that it (already being [status-planned]) was kicked up on the schedule. You can go take a look at the renderer to see why this took a bit, but its out there now.

It should be more or less impossible to accidentally post a spoiler now, as the preview pane will show it.

This would still leave the problem of generating a spoiler unintentionally (even though it probably wouldn't go so far as to actually be posted). So, to mitigate that, the "quote" button on the post editor will no longer generate spoilers***. This was already pretty tricky to do accidentally, as only very short messages would be placed on a single line in a quote.

The quote button will no longer produce spoilers, regardless of the length of the selected text.

On a less technical note, there was some confusion as to how the spoiler syntax actually worked. I blame me. I thought my initial post was clear, but then again of course I knew how it worked. Props to Charles Stewart for drawing my attention to it with his meta.SO post.

The explanation of the spoiler feature has been improved.

_{***This is true for all sane input (where sane ~= contains some whitespace).}

---

TL;DR version

This is a vanishingly rare problem, the proposed solutions have downsides out of proportion with what they're trying to solve (especially in light of its rarity), and steps have been taken to mitigate the issue.

Answer 3

I have another suggestion that could solve the problem:

Change the syntax of the spoiler block across the board.

I understand the desire to use >!, but in light of the clash with TeX error would it be really difficult to change this to a >!! ? For old spoilers this could be done retroactively, (not on TeX.SE...) and the feature is relatively new, so that it should not be a difficult learning experience, For the people who actually use it.