"maxByteLength": backticks to stars

because it denotes a String value

spec.html

@@ -42711,7 +42711,7 @@ <h1>
         </dl>
         <emu-alg>
           1. If _options_ is not an Object, return ~empty~.
-          1. Let _maxByteLength_ be ? Get(_options_, `"maxByteLength"`).
+          1. Let _maxByteLength_ be ? Get(_options_, *"maxByteLength"*).
           1. If _maxByteLength_ is *undefined*, return ~empty~.
           1. Return ? ToIndex(_maxByteLength_).
         </emu-alg>
@@ -43194,15 +43194,15 @@ <h1>Resizable ArrayBuffer Guidelines</h1>
       <emu-note>
         <p>The following are guidelines for ECMAScript programmers working with resizable ArrayBuffer.</p>
         <p>We recommend that programs be tested in their deployment environments where possible. The amount of available physical memory differ greatly between hardware devices. Similarly, virtual memory subsystems also differ greatly between hardware devices as well as operating systems. An application that runs without out-of-memory errors on a 64-bit desktop web browser could run out of memory on a 32-bit mobile web browser.</p>
-        <p>When choosing a value for the `"maxByteLength"` option for resizable ArrayBuffer, we recommend that the smallest possible size for the application be chosen. We recommend that `"maxByteLength"` does not exceed 1073741824, or 1GiB.</p>
+        <p>When choosing a value for the *"maxByteLength"* option for resizable ArrayBuffer, we recommend that the smallest possible size for the application be chosen. We recommend that *"maxByteLength"* does not exceed 1073741824, or 1GiB.</p>
         <p>Please note that successfully constructing a resizable ArrayBuffer for a particular maximum size does not guarantee that future resizes will succeed.</p>
       </emu-note>
 
       <emu-note>
         <p>The following are guidelines for ECMAScript implementers implementing resizable ArrayBuffer.</p>
-        <p>Resizable ArrayBuffer can be implemented as copying upon resize, as in-place growth via reserving virtual memory up front, or as a combination of both for different values of the constructor's `"maxByteLength"` option.</p>
-        <p>If a host is multi-tenanted (i.e. it runs many ECMAScript applications simultaneously), such as a web browser, and its implementations choose to implement in-place growth by reserving virtual memory, we recommend that both 32-bit and 64-bit implementations throw for values of `"maxByteLength"` ≥ 1GiB to 1.5GiB. This is to reduce the likelihood a single application can exhaust the virtual memory address space and to reduce interoperability risk.</p>
-        <p>If a host does not have virtual memory, such as those running on embedded devices without an MMU, or if a host only implements resizing by copying, it may accept any Number value for the `"maxByteLength"` option. However, we recommend a *RangeError* be thrown if a memory block of the requested size can never be allocated. For example, if the requested size is greater than the maximium amount of usable memory on the device.</p>
+        <p>Resizable ArrayBuffer can be implemented as copying upon resize, as in-place growth via reserving virtual memory up front, or as a combination of both for different values of the constructor's *"maxByteLength"* option.</p>
+        <p>If a host is multi-tenanted (i.e. it runs many ECMAScript applications simultaneously), such as a web browser, and its implementations choose to implement in-place growth by reserving virtual memory, we recommend that both 32-bit and 64-bit implementations throw for values of *"maxByteLength"* ≥ 1GiB to 1.5GiB. This is to reduce the likelihood a single application can exhaust the virtual memory address space and to reduce interoperability risk.</p>
+        <p>If a host does not have virtual memory, such as those running on embedded devices without an MMU, or if a host only implements resizing by copying, it may accept any Number value for the *"maxByteLength"* option. However, we recommend a *RangeError* be thrown if a memory block of the requested size can never be allocated. For example, if the requested size is greater than the maximium amount of usable memory on the device.</p>
       </emu-note>
     </emu-clause>
   </emu-clause>
@@ -43483,7 +43483,7 @@ <h1>Growable SharedArrayBuffer Guidelines</h1>
       <emu-note>
         <p>The following are guidelines for ECMAScript programmers working with growable SharedArrayBuffer.</p>
         <p>We recommend that programs be tested in their deployment environments where possible. The amount of available physical memory differ greatly between hardware devices. Similarly, virtual memory subsystems also differ greatly between hardware devices as well as operating systems. An application that runs without out-of-memory errors on a 64-bit desktop web browser could run out of memory on a 32-bit mobile web browser.</p>
-        <p>When choosing a value for the `"maxByteLength"` option for growable SharedArrayBuffer, we recommend that the smallest possible size for the application be chosen. We recommend that `"maxByteLength"` does not exceed 1073741824, or 1GiB.</p>
+        <p>When choosing a value for the *"maxByteLength"* option for growable SharedArrayBuffer, we recommend that the smallest possible size for the application be chosen. We recommend that *"maxByteLength"* does not exceed 1073741824, or 1GiB.</p>
         <p>Please note that successfully constructing a growable SharedArrayBuffer for a particular maximum size does not guarantee that future grows will succeed.</p>
         <p>Not all loads of a growable SharedArrayBuffer's length are synchronizing ~SeqCst~ loads. Loads of the length that are for bounds-checking of an integer-indexed property access, e.g. `u8[idx]`, are not synchronizing. In general, in the absence of explicit synchronization, one property access being in-bound does not imply a subsequent property access in the same agent is also in-bound. In contrast, explicit loads of the length via the `length` and `byteLength` getters on SharedArrayBuffer, %TypedArray%.prototype, and DataView.prototype are synchronizing. Loads of the length that are performed by built-in methods to check if a TypedArray is entirely out-of-bounds are also synchronizing.</p>
       </emu-note>