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 2024-10-30 11:09:38 +01:00 committed by GitHub
parent 3b8f3a09aa
commit 611d6c3e7e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
23 changed files with 60 additions and 61 deletions

View file

@ -148,7 +148,7 @@ to send. The process overall is as follows:
Requests must be made with a `Host` header of
`<delegated_hostname>:<delegated_port>`. The target server must
present a valid certificate for `<delegated_hostname>`.
3. {{< added-in v="1.8" >}} If `<delegated_hostname>` is not an IP literal and no
3. {{% added-in v="1.8" %}} If `<delegated_hostname>` is not an IP literal and no
`<delegated_port>` is present, an SRV record is looked up for
`_matrix-fed._tcp.<delegated_hostname>`. This may result in another
hostname (to be resolved using AAAA or A records) and port.
@ -171,7 +171,7 @@ to send. The process overall is as follows:
`<delegated_hostname>`. The target server must present a valid
certificate for `<delegated_hostname>`.
4. {{< added-in v="1.8" >}} If the `/.well-known` request resulted in an error response, a server is
4. {{% added-in v="1.8" %}} If the `/.well-known` request resulted in an error response, a server is
found by resolving an SRV record for `_matrix-fed._tcp.<hostname>`. This may
result in a hostname (to be resolved using AAAA or A records) and
port. Requests are made to the resolved IP address and port, with a `Host`
@ -375,7 +375,7 @@ The authorization parameters to include are:
- `origin`: the server name of the sending server. This is the same as the
`origin` field from JSON described in step 1.
- `destination`: {{< added-in v="1.3" >}} the server name of the receiving
- `destination`: {{% added-in v="1.3" %}} the server name of the receiving
server. This is the same as the `destination` field from the JSON described
in step 1. For compatibility with older servers, recipients should accept
requests without this parameter, but MUST always send it. If this property
@ -389,7 +389,7 @@ The authorization parameters to include are:
Unknown parameters are ignored.
{{% boxes/note %}}
{{< changed-in v="1.11" >}}
{{% changed-in v="1.11" %}}
This section used to reference [RFC 7235](https://datatracker.ietf.org/doc/html/rfc7235#section-2.1)
and [RFC 7230](https://datatracker.ietf.org/doc/html/rfc9110#section-5.6.2), that
were obsoleted by RFC 9110 without changes to the sections of interest here.
@ -1204,7 +1204,7 @@ Servers MUST use the server described in the [Matrix Content URI](/client-server
Formatted as `mxc://{ServerName}/{MediaID}`, servers MUST download the media from
`ServerName` using the below endpoints.
{{< changed-in v="1.11" >}} Servers were previously advised to use the `/_matrix/media/*`
{{% changed-in v="1.11" %}} Servers were previously advised to use the `/_matrix/media/*`
endpoints described by the [Content Repository module in the Client-Server API](/client-server-api/#content-repository),
however, those endpoints have been deprecated. New endpoints are introduced which
require authentication. Naturally, as a server is not a user, they cannot provide