Merge pull request #2175 from w3c/example-code-xmp

Fix encoding and syntax highlighting of example code

index.bs

@@ -542,7 +542,7 @@ In this flow, the [=[WRP]=] does not have a preference for [=platform authentica
 
 The sample code for generating and registering a new key follows:
 
-<pre class="example" highlight="js">
+<xmp class="example" highlight="js">
     if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }
 
     var publicKey = {
@@ -597,7 +597,7 @@ The sample code for generating and registering a new key follows:
       }).catch(function (err) {
         // No acceptable authenticator or user refused consent. Handle appropriately.
       });
-</pre>
+</xmp>
 
 ### Registration Specifically with User-Verifying Platform Authenticator ### {#sctn-sample-registration-with-platform-authenticator}
 
@@ -619,7 +619,7 @@ a [=user-verifying platform authenticator=].
 
     1. Upon successful credential creation, the [=[RP]=] script conveys the new credential to the server.
 
-<pre class="example" highlight="js">
+<xmp class="example" highlight="js">
     if (!window.PublicKeyCredential) { /* Client not capable of the API. Handle error. */ }
 
     PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
@@ -643,7 +643,7 @@ a [=user-verifying platform authenticator=].
         }).catch(function (err) {
             // Something went wrong. Handle appropriately.
         });
-</pre>
+</xmp>
 
 ### Authentication ### {#sctn-sample-authentication}
 
@@ -685,7 +685,7 @@ credential.
 If the [=[RP]=] script does not have any hints available (e.g., from locally stored data) to help it narrow the list of
 credentials, then the sample code for performing such an authentication might look like this:
 
-<pre class="example" highlight="js">
+<xmp class="example" highlight="js">
     if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }
 
     // credentialId is generated by the authenticator and is an opaque random byte array
@@ -703,12 +703,12 @@ credentials, then the sample code for performing such an authentication might lo
     }).catch(function (err) {
         // No acceptable credential or user refused consent. Handle appropriately.
     });
-</pre>
+</xmp>
 
 On the other hand, if the [=[RP]=] script has some hints to help it narrow the list of credentials, then the sample code for
 performing such an authentication might look like the following. Note that this sample also demonstrates how to use the [=credProps|Credential Properties Extension=].
 
-<pre class="example" highlight="js">
+<xmp class="example" highlight="js">
     if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }
 
     var encoder = new TextEncoder();
@@ -735,14 +735,14 @@ performing such an authentication might look like the following. Note that this
     }).catch(function (err) {
         // No acceptable credential or user refused consent. Handle appropriately.
     });
-</pre>
+</xmp>
 
 ### Aborting Authentication Operations ### {#sctn-sample-aborting}
 
 The below example shows how a developer may use the AbortSignal parameter to abort a
 credential registration operation. A similar procedure applies to an authentication operation.
 
-<pre class="example" highlight="js">
+<xmp class="example" highlight="js">
     const authAbortController = new AbortController();
     const authAbortSignal = authAbortController.signal;
 
@@ -770,7 +770,7 @@ credential registration operation. A similar procedure applies to an authenticat
     if (widget == "disappear") {
         authAbortController.abort();
     }
-</pre>
+</xmp>
 
 
 ### Decommissioning ### {#sctn-sample-decommissioning}
@@ -5680,7 +5680,7 @@ Below is an example of a COSE_Key-encoded Elliptic Curve public key in EC2 forma
 on the P-256 curve, to be used with the ES256 signature
 algorithm (ECDSA w/ SHA-256, see [=Section 2.1=] of [[!RFC9053]]):
 
-<pre class="example" highlight="json">
+<xmp class="example" highlight="cddl">
   {
     1:   2,  ; kty: EC2 key type
     3:  -7,  ; alg: ES256 signature algorithm
@@ -5690,12 +5690,12 @@ algorithm (ECDSA w/ SHA-256, see [=Section 2.1=] of [[!RFC9053]]):
    -3:   y   ; y-coordinate as byte string 32 bytes in length
              ; e.g., in hex: 1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
   }
-</pre>
+</xmp>
 
 Below is the above Elliptic Curve public key encoded in the [=CTAP2 canonical CBOR encoding form=], whitespace and line breaks
 are included here for clarity and to match the CDDL [[!RFC8610]] presentation above:
 
-<pre class="example" highlight="json">
+<xmp class="example">
   A5
      01  02
 
@@ -5706,14 +5706,14 @@ are included here for clarity and to match the CDDL [[!RFC8610]] presentation ab
      21  58 20   65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d
 
      22  58 20   1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
-</pre>
+</xmp>
 
 
 Below is an example of a COSE_Key-encoded 2048-bit RSA public key (see [[RFC8230]] [=Section 4=],
 to be used with the PS256 signature algorithm
 (RSASSA-PSS with SHA-256, see [=RFC8230/Section 2=] of [[RFC8230]]:
 
-<pre class="example" highlight="json">
+<xmp class="example" highlight="cddl">
   {
     1:   3,  ; kty: RSA key type
     3: -37,  ; alg: PS256
@@ -5722,12 +5722,12 @@ to be used with the PS256 signature algorithm
    -2:   e   ; e:   RSA public exponent e byte string 3 bytes in length
              ;      e.g., in hex: 010001
   }
-</pre>
+</xmp>
 
 Below is an example of the same COSE_Key-encoded RSA public key as above,
 to be used with the RS256 signature algorithm (RSASSA-PKCS1-v1_5 with SHA-256):
 
-<pre class="example" highlight="json">
+<xmp class="example" highlight="cddl">
   {
     1:   3,  ; kty: RSA key type
     3:-257,  ; alg: RS256
@@ -5736,7 +5736,7 @@ to be used with the RS256 signature algorithm (RSASSA-PKCS1-v1_5 with SHA-256):
    -2:   e   ; e:   RSA public exponent e byte string 3 bytes in length
              ;      e.g., in hex: 010001
   }
-</pre>
+</xmp>
 
 
 ### Attestation Statement Formats ### {#sctn-attestation-formats}
@@ -7051,7 +7051,7 @@ Note: Other documents have specified extensions where the extension input does n
 as the entry key.
 New extensions SHOULD follow the above convention.
 
-<pre class="example" highlight="js">
+<xmp class="example" highlight="js">
     var assertionPromise = navigator.credentials.get({
         publicKey: {
             // Other members omitted for brevity
@@ -7065,7 +7065,7 @@ New extensions SHOULD follow the above convention.
             }
         }
     });
-</pre>
+</xmp>
 
 Extension definitions MUST specify the valid values for their [=client extension input=]. Clients SHOULD ignore extensions with
 an invalid [=client extension input=]. If an extension does not require any parameters from the [=[RP]=], it SHOULD be defined
@@ -7088,14 +7088,14 @@ The following example defines that an extension with [=extension identifier|iden
 takes an unsigned integer as [=authenticator extension input=],
 and returns an array of at least one byte string as [=authenticator extension output=]:
 
-<pre class="example">
+<xmp class="example" highlight="cddl">
     $$extensionInput //= (
       webauthnExample_foobar: uint
     )
     $$extensionOutput //= (
       webauthnExample_foobar: [+ bytes]
     )
-</pre>
+</xmp>
 
 Note: Extensions should aim to define authenticator arguments that are as small as possible. Some authenticators communicate
     over low-bandwidth links such as Bluetooth Low-Energy or NFC.