Editorial: Name remaining print-ready hyperlinks and unify the format…

… for inline citations

spec.html

@@ -2353,10 +2353,8 @@ <h1>
           <emu-note>
             <p>Implementers of ECMAScript may find useful the paper and code written by David M. Gay for binary-to-decimal conversion of floating-point numbers:</p>
             <p>
-              Gay, David M. Correctly Rounded Binary-Decimal and Decimal-Binary Conversions. Numerical Analysis, Manuscript 90-10. AT&amp;T Bell Laboratories (Murray Hill, New Jersey). 30 November 1990. Available as<br>
-              <a class="print-ready" href="http://ampl.com/REFS/abstracts.html#rounding">http://ampl.com/REFS/abstracts.html#rounding</a>. Associated code available as<br>
-              <a class="print-ready" href="http://netlib.sandia.gov/fp/dtoa.c">http://netlib.sandia.gov/fp/dtoa.c</a> and as<br>
-              <a class="print-ready" href="http://netlib.sandia.gov/fp/g_fmt.c">http://netlib.sandia.gov/fp/g_fmt.c</a> and may also be found at the various `netlib` mirror sites.
+              David M. Gay. <a href="http://ampl.com/REFS/abstracts.html#rounding">Correctly Rounded Binary-Decimal and Decimal-Binary Conversions</a>. Numerical Analysis, Manuscript 90-10. AT&amp;T Bell Laboratories (Murray Hill, New Jersey). 30 November 1990.<br>
+              Associated code is available at any <code>netlib</code> repository mirror in files <a href="http://netlib.sandia.gov/fp/dtoa.c">fp/dtoa.c</a> and <a href="http://netlib.sandia.gov/fp/g_fmt.c">fp/g_fmt.c</a>.
             </p>
           </emu-note>
         </emu-clause>
@@ -31773,7 +31771,7 @@ <h1>Math [ @@toStringTag ]</h1>
       <h1>Function Properties of the Math Object</h1>
       <emu-note>
         <p>The behaviour of the functions `acos`, `acosh`, `asin`, `asinh`, `atan`, `atanh`, `atan2`, `cbrt`, `cos`, `cosh`, `exp`, `expm1`, `hypot`, `log`, `log1p`, `log2`, `log10`, `pow`, `random`, `sin`, `sinh`, `sqrt`, `tan`, and `tanh` is not precisely specified here except to require specific results for certain argument values that represent boundary cases of interest. For other argument values, these functions are intended to compute approximations to the results of familiar mathematical functions, but some latitude is allowed in the choice of approximation algorithms. The general intent is that an implementer should be able to use the same mathematical library for ECMAScript on a given hardware platform that is available to C programmers on that platform.</p>
-        <p>Although the choice of algorithms is left to the implementation, it is recommended (but not specified by this standard) that implementations use the approximation algorithms for IEEE 754-2019 arithmetic contained in `fdlibm`, the freely distributable mathematical library from Sun Microsystems (<a class="print-ready" href="http://www.netlib.org/fdlibm">http://www.netlib.org/fdlibm</a>).</p>
+        <p>Although the choice of algorithms is left to the implementation, it is recommended (but not specified by this standard) that implementations use the approximation algorithms for IEEE 754-2019 arithmetic contained in <a href="http://www.netlib.org/fdlibm"><code>fdlibm</code></a>, the freely distributable mathematical library from Sun Microsystems.</p>
       </emu-note>
 
       <emu-clause id="sec-math.abs">
@@ -42351,9 +42349,9 @@ <h1>WeakMap Objects</h1>
     <p>An implementation may impose an arbitrarily determined latency between the time a key/value pair of a WeakMap becomes inaccessible and the time when the key/value pair is removed from the WeakMap. If this latency was observable to ECMAScript program, it would be a source of indeterminacy that could impact program execution. For that reason, an ECMAScript implementation must not provide any means to observe a key of a WeakMap that does not require the observer to present the observed key.</p>
     <p>WeakMaps must be implemented using either hash tables or other mechanisms that, on average, provide access times that are sublinear on the number of key/value pairs in the collection. The data structure used in this specification is only intended to describe the required observable semantics of WeakMaps. It is not intended to be a viable implementation model.</p>
     <emu-note>
-      <p>WeakMap and WeakSet are intended to provide mechanisms for dynamically associating state with an object or symbol in a manner that does not “leak” memory resources if, in the absence of the WeakMap or WeakSet instance, the object or symbol otherwise became inaccessible and subject to resource reclamation by the implementation's garbage collection mechanisms. This characteristic can be achieved by using an inverted per-object/symbol mapping of WeakMap or WeakSet instances to keys. Alternatively, each WeakMap or WeakSet instance may internally store its key and value data, but this approach requires coordination between the WeakMap or WeakSet implementation and the garbage collector. The following references describe mechanism that may be useful to implementations of WeakMap and WeakSet:</p>
-      <p>Barry Hayes. 1997. Ephemerons: a new finalization mechanism. In <i>Proceedings of the 12th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA '97)</i>, A. Michael Berman (Ed.). ACM, New York, NY, USA, 176-183, <a class="print-ready" href="http://doi.acm.org/10.1145/263698.263733">http://doi.acm.org/10.1145/263698.263733</a>.</p>
-      <p>Alexandra Barros, Roberto Ierusalimschy, Eliminating Cycles in Weak Tables. Journal of Universal Computer Science - J.UCS, vol. 14, no. 21, pp. 3481-3497, 2008, <a class="print-ready" href="http://www.jucs.org/jucs_14_21/eliminating_cycles_in_weak">http://www.jucs.org/jucs_14_21/eliminating_cycles_in_weak</a></p>
+      <p>WeakMap and WeakSet are intended to provide mechanisms for dynamically associating state with an object or symbol in a manner that does not “leak” memory resources if, in the absence of the WeakMap or WeakSet instance, the object or symbol otherwise became inaccessible and subject to resource reclamation by the implementation's garbage collection mechanisms. This characteristic can be achieved by using an inverted per-object/symbol mapping of WeakMap or WeakSet instances to keys. Alternatively, each WeakMap or WeakSet instance may internally store its key and value data, but this approach requires coordination between the WeakMap or WeakSet implementation and the garbage collector. The following references describe mechanisms that may be useful to implementations of WeakMap and WeakSet:</p>
+      <p>Barry Hayes. <a href="http://doi.acm.org/10.1145/263698.263733">Ephemerons: a new finalization mechanism</a>. In <i>Proceedings of the 12th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA '97)</i>, A. Michael Berman (Ed.). ACM, New York, NY, USA, pp. 176-183, 1997.</p>
+      <p>Alexandra Barros, Roberto Ierusalimschy. <a href="http://www.jucs.org/jucs_14_21/eliminating_cycles_in_weak">Eliminating Cycles in Weak Tables</a>. Journal of Universal Computer Science - J.UCS, vol. 14, no. 21, pp. 3481-3497, 2008</p>
     </emu-note>
 
     <emu-clause id="sec-weakmap-constructor">