Apply suggested changes to rich_replies

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This commit is contained in:
Kévin Commaille 2024-11-28 11:30:44 +01:00
parent 9fa9d56515
commit 75b916482e
No known key found for this signature in database
GPG key ID: 0C971D9DBC9D678D

View file

@ -1,15 +1,13 @@
### Rich replies ### Rich replies
{{% changed-in v="1.3" %}}
{{% changed-in v="1.13" %}}
Rich replies are a Rich replies are a
special kind of [relationship](#forming-relationships-between-events) which special kind of [relationship](#forming-relationships-between-events) which
effectively quotes the referenced event for the client to render/process how effectively quotes the referenced event for the client to render/process how
it wishes. They are normally used with [`m.room.message`](#mroommessage) events. it wishes. They are normally used with [`m.room.message`](#mroommessage) events.
{{% boxes/note %}} {{% boxes/note %}}
{{% changed-in v="1.3" %}}
Until v1.3 of the spec, rich replies were limited to `m.room.message` events Until v1.3 of the spec, rich replies were limited to `m.room.message` events
which could represent an HTML-formatted body. As of v1.3 this is now expanded which could represent an HTML-formatted body. As of v1.3 this is now expanded
to *all* event types by dropping the requirement that an HTML-formatted body to *all* event types by dropping the requirement that an HTML-formatted body
@ -22,18 +20,20 @@ Previously, a rich reply could only reference another `m.room.message` event.
{{% boxes/note %}} {{% boxes/note %}}
{{% changed-in v="1.13" %}} {{% changed-in v="1.13" %}}
In previous versions of the specification, rich replies could include a fallback In previous versions of the specification, rich replies could include a fallback
format in the `body` and `formatted_body` for clients that do not support rich representation of the original message message in the `body` (using a prefix
replies, this is no longer the case. Clients might still want to remove this sequence) and `formatted_body` (using a custom HTML element) for clients that do
fallback before rendering the event. not support rich replies. This is no longer the case, but clients SHOULD still
remove this fallback before rendering the event.
To strip the fallback on the `body`, the client should iterate over each To strip the fallback on the `body`, the client should iterate over each
line of the string, removing any lines that start with the fallback line of the string, removing any lines that start with the fallback
prefix ("&gt; ", including the space, without quotes) and stopping when prefix sequence (`> `, including the trailing space) and stopping when
a line is encountered without the prefix. This prefix is known as the a line is encountered without the prefix.
"fallback prefix sequence".
To strip the fallback on the `formatted_body`, the client should remove To strip the fallback on the `formatted_body` of an `m.room.message` event with
the entirety of the `mx-reply` tag. a `format` of `org.matrix.custom.html`: if the`formatted_body` begins with an
`<mx-reply>` start tag, the client should remove the entirety of the
`<mx-reply>` element.
{{% /boxes/note %}} {{% /boxes/note %}}
Though rich replies form a relationship to another event, they do not Though rich replies form a relationship to another event, they do not