Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Should details tags work in comments?
In a post a <details> tag can be used to hide information until a user chooses to click on it, useful for spoilers or puzzle solutions.
For example, the following raw text:
<details>
<summary>
Click to see the answer
</summary>
The answer is "Ask why 5 times"
</details>
is rendered as:
Click to see the answer
The answer is "Ask why 5 times"Currently comments support some HTML, such as bold, italics and supercript. Would it be useful for comments to also support hidden information with the <details> tag?
Even if it didn't actively encourage misuse of the site, time spent on a feature like this would be far better used else …
5mo ago
Comments aren't for content. They are for working with the author to make a better post. Put another way, they are sup …
5mo ago
I can imagine the following uses for hidden `` sections in comment threads. Some of these uses will apply to some types …
5mo ago
I started to write a whole thing about how "this might make sense if each community could turn it on or off," and explai …
5mo ago
4 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
Even if it didn't actively encourage misuse of the site, time spent on a feature like this would be far better used elsewhere.
<details> tags are already sufficient to implement a "spoiler" within an answer. If for some reason it were necessary to mark comment content as a spoiler - for example, discussing a candidate puzzle solution - keep in mind that comment threads are already hidden by default: they're collapsed behind the thread title. The appropriate course of action is to use a separate comment thread and title it in a way that gives suitable warning. Content that needs to be marked this way shouldn't be dropped into an existing comment thread anyway.
Regarding debugging: comments have a much shorter character limit anyway. A long log simply isn't going to fit into 1000 characters, so it couldn't be posted in a comment. Comments that fit the line limit aren't going to need collapsing for space unless they're abusing line breaks (which is probably flaggable anyway).
Comments aren't for content. They are for working with the author to make a better post. Put another way, they are supposed to be meta about the post.
While some basic formatting can be useful, there is no need for "fancy" formatting to serve the meta purpose. There is very little legitimate reason to add spoiler blocks to comments when those comments are used for the correct purpose. We already see too much abuse of comments. Adding spoiler blocks would only encourage more.
0 comment threads
I can imagine the following uses for hidden <details> sections in comment threads. Some of these uses will apply to some types of Codidact community, and other uses will apply to other types. Even though not all communities will necessarily have a use for them, the fact that some communities will have some of these uses for them makes me in favour of hidden <details> sections being available in comments.
I don't see this as an urgent need, but it is something I would like to see in the long term.
Long output such as log files
Sometimes information needs to be shared that would be disruptive to the flow of reading a comment thread if included at full length. For example, if a comment thread involves several comments back and forth helping narrow down which log file is required, there may be several comments each with pages long logs. If all of these show at full length then the reader needs to scroll down a long way to find the conclusion, even if they only need to see the latest log. Hidden sections would make it more convenient to help someone who isn't sure what information to include in their question, or who isn't sure how to apply the instructions given in an answer.
I can imagine this being relevant to the following communities:
- Software Development
- Code Golf
- Linux Systems
- Power Users
Puzzle solutions
We don't yet have a Puzzles Codidact community, but there is one in the Proposals community. Even before this is launched as a separate community, people are free to post questions and answers there to explore the scope, so being able to hide puzzle solutions during discussion threads could already be useful.
I can imagine this being relevant to the following communities:
- Puzzles
- Code Golf
Spoilers
In addition to avoiding spoiling a plot point of a story (such as a movie or novel), it could also be useful to avoid giving away a full solution when giving a hint at how to solve a problem. Unlike puzzles, problems (whether in coding, cooking, or mathematics) tend to have multiple valid solutions, so hiding the writer's particular solution can allow the reader to find their own without being influenced, and then compare the differences.
I can imagine this being relevant to the following communities:
- Writing
- Software Development
- Code Golf
- Cooking
- Mathematics
- Physics
- Scientific Speculation
- Music
I started to write a whole thing about how "this might make sense if each community could turn it on or off," and explaining the difference in my eyes.
However, my counter-example started out as a programming question-and-answer, and I realized that...
First, you often want to ask a technical question by loading information into it (logs, for example), but you don't want that mass of content to clutter the question to the point that nobody reads it.
Likewise, a programming answer especially might come in two forms, the "this is the thing that you need to fix to get your presented code running" answer and the "here's your code rewritten to not only fix your problem but head off some other potential issues.
Combine those cases with (in effect) spoiler warnings (presumably the originally envisioned use, when calling about puzzles) and content warnings when somebody needs to present information that some readers will want to skip, and details start to make a lot of sense across the board...assuming that implementing it - in a way that makes sense for users who aren't comfortable with "just mix Markdown and HTML - wouldn't take too much effort, of course.
1 comment thread