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:
parent
3b8f3a09aa
commit
611d6c3e7e
23 changed files with 60 additions and 61 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue