Always use % delimiter for added-in and changed-in shortcodes (#1975)
The `<>` delimiters are not necessary for the shortcode to be rendered inline, and in some cases they break some expectations: a shortcode that is separated from other text to be in its own paragraph is not actually wrapped by a `p` element, breaking the spacing between paragraphs. Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This commit is contained in:
Kévin Commaille
GitHub
parent
3b8f3a09aa
commit
611d6c3e7e
23 changed files with 60 additions and 61 deletions
|
|
@ -16,12 +16,12 @@ When serving content, the server SHOULD provide a
|
|||
`Content-Security-Policy` header. The recommended policy is
|
||||
`sandbox; default-src 'none'; script-src 'none'; plugin-types application/pdf; style-src 'unsafe-inline'; object-src 'self';`.
|
||||
|
||||
{{< added-in v="1.4" >}} The server SHOULD additionally provide
|
||||
{{% added-in v="1.4" %}} The server SHOULD additionally provide
|
||||
`Cross-Origin-Resource-Policy: cross-origin` when serving content to allow
|
||||
(web) clients to access restricted APIs such as `SharedArrayBuffer` when
|
||||
interacting with the media repository.
|
||||
|
||||
{{< changed-in v="1.11" >}} The unauthenticated download endpoints have been
|
||||
{{% changed-in v="1.11" %}} The unauthenticated download endpoints have been
|
||||
deprecated in favour of newer, authenticated, ones. This change includes updating
|
||||
the paths of all media endpoints from `/_matrix/media/*` to `/_matrix/client/{version}/media/*`,
|
||||
with the exception of the `/upload` and `/create` endpoints. The upload/create
|
||||
|
|
@ -44,7 +44,7 @@ mxc://<server-name>/<media-id>
|
|||
|
||||
Clients can access the content repository using the following endpoints.
|
||||
|
||||
{{< changed-in v="1.11" >}} A number of endpoints under the /_matrix/media hierarchy
|
||||
{{% changed-in v="1.11" %}} A number of endpoints under the /_matrix/media hierarchy
|
||||
have been deprecated and replaced with new endpoints which require authentication.
|
||||
The deprecated endpoints are marked in the section below.
|
||||
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ replacement event.
|
|||
|
||||
##### Server-side aggregation of `m.replace` relationships
|
||||
|
||||
{{< changed-in v="1.7" >}}
|
||||
{{% changed-in v="1.7" %}}
|
||||
|
||||
Note that there can be multiple events with an `m.replace` relationship to a
|
||||
given event (for example, if an event is edited multiple times). These should
|
||||
|
|
|
|||
|
|
@ -40,13 +40,13 @@ for retrieving events and associated media:
|
|||
* [GET /rooms/{roomId}/event/{eventId}](#get_matrixclientv3roomsroomideventeventid)
|
||||
* [GET /rooms/{roomId}/state/{eventType}/{stateKey}](#get_matrixclientv3roomsroomidstateeventtypestatekey)
|
||||
* [GET /rooms/{roomId}/messages](#get_matrixclientv3roomsroomidmessages)
|
||||
* {{< added-in v="1.1" >}} [GET /rooms/{roomId}/members](#get_matrixclientv3roomsroomidmembers)
|
||||
* {{% added-in v="1.1" %}} [GET /rooms/{roomId}/members](#get_matrixclientv3roomsroomidmembers)
|
||||
* [GET /rooms/{roomId}/initialSync](#get_matrixclientv3roomsroomidinitialsync)
|
||||
* [GET /sync](#get_matrixclientv3sync)
|
||||
* [GET /events](#get_matrixclientv3events) as used for room previews.
|
||||
* {{< added-in v="1.12" >}} [GET /media/download/{serverName}/{mediaId}](#get_matrixclientv1mediadownloadservernamemediaid)
|
||||
* {{< added-in v="1.12" >}} [GET /media/download/{serverName}/{mediaId}/{fileName}](#get_matrixclientv1mediadownloadservernamemediaidfilename)
|
||||
* {{< added-in v="1.12" >}} [GET /media/thumbnail/{serverName}/{mediaId}](#get_matrixclientv1mediathumbnailservernamemediaid)
|
||||
* {{% added-in v="1.12" %}} [GET /media/download/{serverName}/{mediaId}](#get_matrixclientv1mediadownloadservernamemediaid)
|
||||
* {{% added-in v="1.12" %}} [GET /media/download/{serverName}/{mediaId}/{fileName}](#get_matrixclientv1mediadownloadservernamemediaidfilename)
|
||||
* {{% added-in v="1.12" %}} [GET /media/thumbnail/{serverName}/{mediaId}](#get_matrixclientv1mediathumbnailservernamemediaid)
|
||||
|
||||
The following API endpoints are allowed to be accessed by guest accounts
|
||||
for sending events:
|
||||
|
|
@ -55,9 +55,9 @@ for sending events:
|
|||
* [POST /rooms/{roomId}/leave](#post_matrixclientv3roomsroomidleave)
|
||||
* [PUT /rooms/{roomId}/send/{eventType}/{txnId}](#put_matrixclientv3roomsroomidsendeventtypetxnid)
|
||||
|
||||
* {{< changed-in v="1.2" >}} Guests can now send *any* event type rather than just `m.room.message` events.
|
||||
* {{% changed-in v="1.2" %}} Guests can now send *any* event type rather than just `m.room.message` events.
|
||||
|
||||
* {{< added-in v="1.2" >}} [PUT /rooms/{roomId}/state/{eventType}/{stateKey}](#put_matrixclientv3roomsroomidstateeventtypestatekey)
|
||||
* {{% added-in v="1.2" %}} [PUT /rooms/{roomId}/state/{eventType}/{stateKey}](#put_matrixclientv3roomsroomidstateeventtypestatekey)
|
||||
* [PUT /sendToDevice/{eventType}/{txnId}](#put_matrixclientv3sendtodeviceeventtypetxnid)
|
||||
|
||||
The following API endpoints are allowed to be accessed by guest accounts
|
||||
|
|
@ -67,7 +67,7 @@ for their own account maintenance:
|
|||
* [GET /devices](#get_matrixclientv3devices)
|
||||
* [GET /devices/{deviceId}](#get_matrixclientv3devicesdeviceid)
|
||||
* [PUT /devices/{deviceId}](#put_matrixclientv3devicesdeviceid)
|
||||
* {{< added-in v="1.2" >}} [GET /account/whoami](#get_matrixclientv3accountwhoami)
|
||||
* {{% added-in v="1.2" %}} [GET /account/whoami](#get_matrixclientv3accountwhoami)
|
||||
|
||||
The following API endpoints are allowed to be accessed by guest accounts
|
||||
for end-to-end encryption:
|
||||
|
|
|
|||
|
|
@ -525,7 +525,7 @@ Definition:
|
|||
|
||||
<a id="_m_rule_is_user_mention"></a> **`.m.rule.is_user_mention`**
|
||||
|
||||
{{< added-in v="1.7" >}}
|
||||
{{% added-in v="1.7" %}}
|
||||
|
||||
Matches any message which contains the user's Matrix ID in the list of `user_ids`
|
||||
under the `m.mentions` property.
|
||||
|
|
@ -594,7 +594,7 @@ Definition:
|
|||
|
||||
<a id="_m_rule_is_room_mention"></a> **`.m.rule.is_room_mention`**
|
||||
|
||||
{{< added-in v="1.7" >}}
|
||||
{{% added-in v="1.7" %}}
|
||||
|
||||
Matches any message from a sender with the proper power level with the `room`
|
||||
property of the `m.mentions` property set to `true`.
|
||||
|
|
@ -1072,7 +1072,7 @@ ahead), however if the `m.read.private` receipt were to be updated to
|
|||
event D then the user has read up to D (the `m.read` receipt is now
|
||||
behind the `m.read.private` receipt).
|
||||
|
||||
{{< added-in v="1.4" >}} When handling threaded read receipts, the server is to
|
||||
{{% added-in v="1.4" %}} When handling threaded read receipts, the server is to
|
||||
partition the notification count to each thread (with the main timeline being
|
||||
its own thread). To determine if an event is part of a thread the server follows
|
||||
the [event relationship](#forming-relationships-between-events) until it finds a
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The client cannot update fully read markers by directly modifying the
|
|||
`m.fully_read` account data event. Instead, the client must make use of
|
||||
the read markers API to change the values.
|
||||
|
||||
{{< changed-in v="1.4" >}} `m.read.private` receipts can now be sent from
|
||||
{{% changed-in v="1.4" %}} `m.read.private` receipts can now be sent from
|
||||
`/read_markers`.
|
||||
|
||||
The read markers API can additionally update the user's read receipt
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
### Receipts
|
||||
|
||||
{{< changed-in v="1.4" >}} Added private read receipts.
|
||||
{{% changed-in v="1.4" %}} Added private read receipts.
|
||||
|
||||
This module adds in support for receipts. These receipts are a form of
|
||||
acknowledgement of an event. This module defines the `m.read` receipt
|
||||
|
|
@ -19,7 +19,7 @@ that the user had read all events *up to* the referenced event. See the
|
|||
[Receiving notifications](#receiving-notifications) section for more
|
||||
information on how read receipts affect notification counts.
|
||||
|
||||
{{< added-in v="1.4" >}} Read receipts exist in three major forms:
|
||||
{{% added-in v="1.4" %}} Read receipts exist in three major forms:
|
||||
* Unthreaded: Denotes a read-up-to receipt regardless of threads. This is how
|
||||
pre-threading read receipts worked.
|
||||
* Threaded, main timeline: Denotes a read-up-to receipt for events not in a
|
||||
|
|
@ -31,7 +31,7 @@ Threaded read receipts are discussed in further detail [below](#threaded-read-re
|
|||
|
||||
#### Events
|
||||
|
||||
{{< changed-in v="1.4" >}} Each `user_id`, `receipt_type`, and categorisation
|
||||
{{% changed-in v="1.4" %}} Each `user_id`, `receipt_type`, and categorisation
|
||||
(unthreaded, or `thread_id`) tuple must be associated with only a single
|
||||
`event_id`.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ Threaded read receipts are discussed in further detail [below](#threaded-read-re
|
|||
|
||||
#### Client behaviour
|
||||
|
||||
{{< changed-in v="1.4" >}} Altered to support threaded read receipts.
|
||||
{{% changed-in v="1.4" %}} Altered to support threaded read receipts.
|
||||
|
||||
In `/sync`, receipts are listed under the `ephemeral` array of events
|
||||
for a given room. New receipts that come down the event streams are
|
||||
|
|
|
|||
|
|
@ -21,11 +21,11 @@ rooms instead of individual events. Server administrators and safety teams
|
|||
should, therefore, be cautious not to shut down rooms that might otherwise
|
||||
be legitimate.
|
||||
|
||||
{{< changed-in v="1.8" >}} When processing event reports, servers MUST
|
||||
{{% changed-in v="1.8" %}} When processing event reports, servers MUST
|
||||
verify that the reporting user is currently joined to the room the event
|
||||
is in before accepting a report.
|
||||
|
||||
{{< added-in v="1.12" >}} Contrarily, servers MUST NOT restrict room reports
|
||||
{{% added-in v="1.12" %}} Contrarily, servers MUST NOT restrict room reports
|
||||
based on whether or not the reporting user is joined to the room. This is
|
||||
because users can be exposed to harmful content without being joined to a
|
||||
room. For instance, through room directories or invites.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ server:
|
|||
1. Checks that the user has permission to send `m.room.tombstone`
|
||||
events in the room.
|
||||
|
||||
2. {{< changed-in v="1.4" >}} Creates a replacement room with a `m.room.create` event containing a
|
||||
2. {{% changed-in v="1.4" %}} Creates a replacement room with a `m.room.create` event containing a
|
||||
`predecessor` field, the applicable `room_version`, and a `type` field
|
||||
which is copied from the `predecessor` room. If no `type` is set on the
|
||||
previous room, no `type` is specified on the new room's create event
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue