MSC2557: Proposal to clarify spoilers

proposals/2010-spoilers.md

@@ -3,25 +3,28 @@ Sometimes, while you want to put text into a spoiler to not have people accident
 
 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.  
+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
-trigger anyone just reading along the conversation.  
+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).
 
 ## Proposal
 This proposal is about adding a new attribute to the `formatted_body` of messages with type
-`m.room.message` and msgtype `m.text`.
+`m.room.message` and message types which support the `org.matrix.custom.html` format.
 
 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)
 
+The plaintext fallback supported by the `body` is optional. A recommendation for clients is included
+below.
+
 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.

proposals/2557-spoiler-clarifications.md

@@ -0,0 +1,20 @@
+# MSC2557: Clarifications on spoilers
+
+Spoiler messages are described in [MSC2010](https://github.com/matrix-org/matrix-doc/pull/2010)
+though the MSC is unclear if the fallback is required to be sent by clients.
+
+## Proposal
+
+The fallback for spoiler messages is optional, though recommended to be sent by clients. Clients
+should make reasonable efforts to represent the spoiler in the `body` field of a message.
+
+The recommended fallback format is unchanged.
+
+Additionally, this proposal opens up spoilers to any HTML-supporting message types. Currently
+this includes `m.text` (already included by MSC2010), `m.notice`, and `m.emote`.
+
+## Potential issues
+
+Clients could inadvertently spoil parts of a message by not representing the spoiler correctly
+in the `body` of the message. The author believes this would quickly show up as a bug report
+on the client due to the nature of spoilers.