Always use % delimiter with changed-in shortcode

Signed-off-by: Kévin Commaille <[email protected]>

content/appendices.md

@@ -761,7 +761,7 @@ wish to consider handling them as `u`, `r`, and `e` respectively.
 {{% /boxes/note %}}
 
 {{% boxes/note %}}
-{{< changed-in v="1.11" >}}
+{{% changed-in v="1.11" %}}
 Referencing event IDs within a room identified by room alias (`r`) rather than room ID
 (`roomid`) is now deprecated. We are not aware of these ever having been used in
 practice, and are nonsensical given room aliases are mutable.
@@ -858,7 +858,7 @@ Examples of matrix.to URIs are:
 * Link to `@alice:example.org`: `https://matrix.to/#/%40alice%3Aexample.org`
 
 {{% boxes/note %}}
-{{< changed-in v="1.11" >}}
+{{% changed-in v="1.11" %}}
 Referencing event IDs within a room identified by room alias rather than room ID
 is now deprecated. We are not aware of these ever having been used in
 practice, and are nonsensical given room aliases are mutable.

content/client-server-api/_index.md

@@ -242,7 +242,8 @@ The `retry_after_ms` property MAY be included to tell the client how long
 they have to wait in milliseconds before they can try again. This property is
 deprecated, in favour of the `Retry-After` header.
 
-{{< changed-in v="1.10" >}}: `retry_after_ms` property deprecated in favour of `Retry-After` header.
+{{% changed-in v="1.10" %}}: `retry_after_ms` property deprecated in favour of `Retry-After` header.
+
 ### Transaction identifiers
 
 The client-server API typically uses `HTTP PUT` to submit requests with

content/client-server-api/modules/content_repo.md

@@ -21,7 +21,7 @@ When serving content, the server SHOULD provide a
 (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.
 

content/client-server-api/modules/event_replacements.md

@@ -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

content/client-server-api/modules/guest_access.md

@@ -55,7 +55,7 @@ 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)
 * [PUT /sendToDevice/{eventType}/{txnId}](#put_matrixclientv3sendtodeviceeventtypetxnid)

content/client-server-api/modules/read_markers.md

@@ -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

content/client-server-api/modules/receipts.md

@@ -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
@@ -31,15 +31,15 @@ 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`.
 
 {{% event event="m.receipt" %}}
 
 #### 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

content/client-server-api/modules/report_content.md

@@ -21,7 +21,7 @@ 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.
 

content/client-server-api/modules/room_upgrades.md

@@ -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

content/rooms/v10.md

@@ -141,7 +141,7 @@ The rules are as follows:
  3. If the `sender` is banned, reject.
  4. If the `join_rule` is `invite` or `knock` then allow if
  membership state is `invite` or `join`.
- 5. {{< changed-in v=10 >}}
+ 5. {{% changed-in v=10 %}}
  If the `join_rule` is `restricted` or `knock_restricted`:
  1. If membership state is `join` or `invite`, allow.
  2. If the `join_authorised_via_users_server` key in `content`
@@ -197,7 +197,7 @@ The rules are as follows:
  than the `sender`'s power level, allow.
  3. Otherwise, reject.
  7. If `membership` is `knock`:
- 1. {{< changed-in v=10 >}}
+ 1. {{% changed-in v=10 %}}
  If the `join_rule` is anything other than `knock` or
  `knock_restricted`, reject.
  2. If `sender` does not match `state_key`, reject.

content/rooms/v11.md

@@ -112,7 +112,7 @@ the [Handling redactions](#handling-redactions) section.
 
 The rules are as follows:
 
-1. {{< changed-in v=11 >}}
+1. {{% changed-in v=11 %}}
  If type is `m.room.create`:
  1. If it has any `prev_events`, reject.
  2. If the domain of the `room_id` does not match the domain of the
@@ -142,7 +142,7 @@ The rules are as follows:
  1. If the event is not validly signed by the homeserver of the user ID denoted
  by the key, reject.
  3. If `membership` is `join`:
- 1. {{< changed-in v=11 >}}
+ 1. {{% changed-in v=11 %}}
  If the only previous event is an `m.room.create` and the
  `state_key` is the sender, allow.
  2. If the `sender` does not match `state_key`, reject.

content/rooms/v6.md

@@ -175,12 +175,12 @@ The rules are as follows:
  power level, reject.
  2. If the new value is higher than the `sender`'s current power
  level, reject.
- 4. {{< changed-in v=6 >}}
+ 4. {{% changed-in v=6 %}}
  For each entry being changed in, or removed from, the `events` or
  `notifications` properties:
  1. If the current value is greater than the `sender`'s current
  power level, reject.
- 5. {{< changed-in v=6 >}}
+ 5. {{% changed-in v=6 %}}
  For each entry being added to, or changed in, the `events` or
  `notifications` properties:
  1. If the new value is greater than the `sender`'s current power

content/rooms/v7.md

@@ -90,7 +90,7 @@ The rules are as follows:
  `state_key` is the creator, allow.
  2. If the `sender` does not match `state_key`, reject.
  3. If the `sender` is banned, reject.
- 4. {{< changed-in v=7 >}}
+ 4. {{% changed-in v=7 %}}
  If the `join_rule` is `invite` or `knock` then allow if
  membership state is `invite` or `join`.
  5. If the `join_rule` is `public`, allow.
@@ -122,7 +122,7 @@ The rules are as follows:
  the *invite level*, allow.
  5. Otherwise, reject.
  4. If `membership` is `leave`:
- 1. {{< changed-in v=7 >}}
+ 1. {{% changed-in v=7 %}}
  If the `sender` matches `state_key`, allow if and only if
  that user's current membership state is `invite`, `join`,
  or `knock`.

content/server-server-api.md

@@ -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

data/api/client-server/content-repo.yaml

@@ -229,7 +229,7 @@ paths:
  {{% /boxes/note %}}
 
  {{% boxes/warning %}}
- {{< changed-in v="1.11" >}} This endpoint MAY return `404 M_NOT_FOUND`
+ {{% changed-in v="1.11" %}} This endpoint MAY return `404 M_NOT_FOUND`
  for media which exists, but is after the server froze unauthenticated
  media access. See [Client Behaviour](/client-server-api/#content-repo-client-behaviour) for more
  information.
@@ -303,7 +303,7 @@ paths:
  provided by the caller.
 
  {{% boxes/warning %}}
- {{< changed-in v="1.11" >}} This endpoint MAY return `404 M_NOT_FOUND`
+ {{% changed-in v="1.11" %}} This endpoint MAY return `404 M_NOT_FOUND`
  for media which exists, but is after the server froze unauthenticated
  media access. See [Client Behaviour](/client-server-api/#content-repo-client-behaviour) for more
  information.
@@ -375,7 +375,7 @@ paths:
  See the [Thumbnails](/client-server-api/#thumbnails) section for more information.
 
  {{% boxes/warning %}}
- {{< changed-in v="1.11" >}} This endpoint MAY return `404 M_NOT_FOUND`
+ {{% changed-in v="1.11" %}} This endpoint MAY return `404 M_NOT_FOUND`
  for media which exists, but is after the server froze unauthenticated
  media access. See [Client Behaviour](/client-server-api/#content-repo-client-behaviour) for more
  information.