You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec/proposals/2010-spoilers.md

75 lines
3.5 KiB
Markdown

6 years ago
# MSC 2010: Proposal to add client-side spoilers
Sometimes, while you want to put text into a spoiler to not have people accidentally read things that they don't want to see.
6 years ago
For example, when discussing a new movie or a TV series, not everyone might have watched it yet.
In such cases it would make sense to add a spoiler so that only those who have seen the movie or
don't mind spoilers read the content.
Another example would be e.g. in mental health communities where certain people have certain
triggers. People could put talking about abuse or the like into a spoiler, to not accidentally
6 years ago
trigger anyone just reading along the conversation.
Furthermore this is helpful for bridging to other networks that already have a spoiler feature.
6 years ago
6 years ago
To render the spoiler the content is hidden and then revealed once interacted somehow
(e.g. a click / hover).
6 years ago
## Proposal
6 years ago
This proposal is about adding a new attribute to the `formatted_body` of messages with type
`m.room.message` and msgtype `m.text`.
6 years ago
It adds a new attribute, `data-mx-spoiler`, to the `<span>` tag. If the attribute is present the
contents of the span tag should be rendered as a spoiler. Optionally, you can specify a reason for
the spoiler by setting the attribute string. It could be rendered, for example, similar to this:
![Spoiler rendering idea](images/2010-spoiler-example.gif)
6 years ago
To preserve the semantics of a spoiler in the plaintext fallback it is recommended to upload the contents of the spoiler
as a text file and then link this: `[Spoiler](mxc://someserver/somefile)` and
`[Spoiler for reason](mxc://someserver/somefile)` respectively.
6 years ago
### Example
Without reason:
```
{
"msgtype": "m.text",
"format": "org.matrix.custom.html",
"body": "Hello there, the movie was [spoiler](mxc://someserver/somefile)",
"formatted_body": "Hello there, the movie was <span data-mx-spoiler>awesome</span>"
}
```
With reason:
```
{
"msgtype": "m.text",
"format": "org.matrix.custom.html",
"body": "Hey [Spoiler for movie](mxc://someserver/somefile)",
"formatted_body": "Hey <span data-mx-spoiler="movie">the movie was awesome</span>"
}
```
6 years ago
## Tradeoffs
6 years ago
Instead of making this an attribute, an entirely new tag could be introduced (e.g. `<mx-spoiler>`),
however that wouldn't be HTML-compliant.
6 years ago
6 years ago
Instead of limiting the proposed `data-mx-spoiler` attribute only to the `<span>`-tag it could be
added to all tags, however it might make implementations for clients more complicated.
6 years ago
Alternatively the [details](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details) tag could
be used. This, however, is a block element, and the spoilers are span elements. Furthermore
semantically there is a slight difference: with the details tag you hide something for a person
as it uses up a lot of screen space, while with a spoiler you hide something as a person might not
want to see it.
6 years ago
## Potential issues
6 years ago
Depending on context it might make sense to put other events, such as `m.image`, into spoilers,
too. This MSC doesn't address that at all. Using
`<span data-mx-spoiler><img src="mxc://server/media"></span>` seems rather sub-optimal for that.
6 years ago
This MSC doesn't take HTML block elements into account.
Clients would have to come up with a way to input spoilers. This could be done, for example,
by adding a custom markdown tag (like discord does), so that you do `Text ||spoiler||`, however
that doesn't take a spoiler reason into account.
6 years ago
## Security considerations
The spoiler reason needs to be properly escaped when rendered.