From 273af2a2e0eb3351ad58bf39c1e2472a3c96881d Mon Sep 17 00:00:00 2001 From: Sorunome Date: Wed, 22 May 2019 17:30:18 +0200 Subject: [PATCH] wrap long lines --- proposals/2010-spoilers.md | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/proposals/2010-spoilers.md b/proposals/2010-spoilers.md index d4128de41..366f4a3eb 100644 --- a/proposals/2010-spoilers.md +++ b/proposals/2010-spoilers.md @@ -1,20 +1,29 @@ # 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. -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 thelike into a spoiler, to not accidentally trigger anyone just reading along the conversation. +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 thelike into a spoiler, to not accidentally +trigger anyone just reading along the conversation. Furthermore this is helpful for bridging to other networks that already have a spoiler feature. -To render the spoiler the content is hidden and then revealed once interacted somehow (e.g. a click / hover). +To render the spoiler the content is hidden and then revealed once interacted somehow +(e.g. a click / hover). ## Proposal -This proposal is about adding a new attribute to the `formatted_body` of messages with type `m.room.message` and msgtype `m.text`. +This proposal is about adding a new attribute to the `formatted_body` of messages with type +`m.room.message` and msgtype `m.text`. -It adds a new attribute, `data-mx-spoiler`, to the `` 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: +It adds a new attribute, `data-mx-spoiler`, to the `` 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](https://user-images.githubusercontent.com/2433620/58178745-082c1480-7ca7-11e9-901b-13b147cfd157.png) -The plain-text fallback could be rendered as `(Spoiler: )` and `(Spoiler for : )` respectively. +The plain-text fallback could be rendered as `(Spoiler: )` and +`(Spoiler for : )` respectively. ### Example Without reason: @@ -37,14 +46,20 @@ With reason: ``` ## Tradeoffs -Instead of making this an attribute, an entirely new tag could be introduced (e.g. ``), however that wouldn't be HTML-compliant. +Instead of making this an attribute, an entirely new tag could be introduced (e.g. ``), +however that wouldn't be HTML-compliant. -Instead of limiting the proposed `data-mx-spoiler` attribute only to the ``-tag it could be added to all tags, however it might make implementations for clients more complicated. +Instead of limiting the proposed `data-mx-spoiler` attribute only to the ``-tag it could be +added to all tags, however it might make implementations for clients more complicated. -Clients would have to come up with a way how 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. +Clients would have to come up with a way how 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. ## Potential issues -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 `` seems rather sub-optimal for that. +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 +`` seems rather sub-optimal for that. This MSC doesn't take HTML block elements into account.