Editorial: Use <code> for values from other specifications

spec.html

@@ -34070,7 +34070,7 @@ <h1>String.prototype.toLowerCase ( )</h1>
           1. Let _L_ be ! CodePointsToString(_lowerText_).
           1. Return _L_.
         </emu-alg>
-        <p>The result must be derived according to the locale-insensitive case mappings in the Unicode Character Database (this explicitly includes not only the UnicodeData.txt file, but also all locale-insensitive mappings in the SpecialCasings.txt file that accompanies it).</p>
+        <p>The result must be derived according to the locale-insensitive case mappings in the Unicode Character Database (this explicitly includes not only the file <a href="https://unicode.org/Public/UCD/latest/ucd/UnicodeData.txt"><code>UnicodeData.txt</code></a>, but also all locale-insensitive mappings in the file <a href="https://unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt"><code>SpecialCasing.txt</code></a> that accompanies it).</p>
         <emu-note>
           <p>The case mapping of some code points may produce multiple code points. In this case the result String may not be the same length as the source String. Because both `toUpperCase` and `toLowerCase` have context-sensitive behaviour, the functions are not symmetrical. In other words, `s.toUpperCase().toLowerCase()` is not necessarily equal to `s.toLowerCase()`.</p>
         </emu-note>
@@ -35466,7 +35466,7 @@ <h1>
           </dl>
           <emu-alg>
             1. If _Unicode_ is *true* and _IgnoreCase_ is *true*, then
-              1. If the file CaseFolding.txt of the Unicode Character Database provides a simple or common case folding mapping for _ch_, return the result of applying that mapping to _ch_.
+              1. If the file <a href="https://unicode.org/Public/UCD/latest/ucd/CaseFolding.txt"><code>CaseFolding.txt</code></a> of the Unicode Character Database provides a simple or common case folding mapping for _ch_, return the result of applying that mapping to _ch_.
               1. Return _ch_.
             1. If _IgnoreCase_ is *false*, return _ch_.
             1. Assert: _ch_ is a UTF-16 code unit.
@@ -46059,7 +46059,7 @@ <h1>Shared Memory Guidelines</h1>
       <p>That mapping is correct so long as an atomic operation on an address range does not race with a non-atomic write or with an atomic operation of different size. However, that is all we need: the memory model effectively demotes the atomic operations involved in a race to non-atomic status. On the other hand, the naive mapping is quite strong: it allows atomic operations to be used as sequentially consistent fences, which the memory model does not actually guarantee.</p>
       <p>A number of local improvements to those basic patterns are also intended to be legal:</p>
       <ul>
-        <li>There are obvious platform-dependent improvements that remove redundant fences. For example, on x86 the fences around lock-free atomic loads and stores can always be omitted except for the fence following a store, and no fence is needed for lock-free read-modify-write instructions, as these all use LOCK-prefixed instructions. On many platforms there are fences of several strengths, and weaker fences can be used in certain contexts without destroying sequential consistency.</li>
+        <li>There are obvious platform-dependent improvements that remove redundant fences. For example, on x86 the fences around lock-free atomic loads and stores can always be omitted except for the fence following a store, and no fence is needed for lock-free read-modify-write instructions, as these all use <code>LOCK</code>-prefixed instructions. On many platforms there are fences of several strengths, and weaker fences can be used in certain contexts without destroying sequential consistency.</li>
         <li>Most modern platforms support lock-free atomics for all the data sizes required by ECMAScript atomics. Should non-lock-free atomics be needed, the fences surrounding the body of the atomic operation can usually be folded into the lock and unlock steps. The simplest solution for non-lock-free atomics is to have a single lock word per SharedArrayBuffer.</li>
         <li>There are also more complicated platform-dependent local improvements, requiring some code analysis. For example, two back-to-back fences often have the same effect as a single fence, so if code is generated for two atomic operations in sequence, only a single fence need separate them. On x86, even a single fence separating atomic stores can be omitted, as the fence following a store is only needed to separate the store from a subsequent load.</li>
       </ul>