Unescape entities

* Unicode is cool!
* We have to leave the GRAVE alone otherwise markdown gets confused
* Also `<` and `>` to stop accidental HTMLification
* As per #1193

sections/acknowledgements.include

@@ -337,7 +337,7 @@
   Csaba Gabor,
   Csaba Marton,
   C. Williams,
-  Cătălin Mariș,
+  Cătălin Mariș,
   Cynthia Shelly,
   Cyril Concolato,
   Dan Brickley,
@@ -472,7 +472,7 @@
   Frank Liberato,
   Frank Olivier,
   Fredrik Söderquist,
-  鵜飼文敏 (Fumitoshi Ukai),
+  鵜飼文敏 (Fumitoshi Ukai),
   Fuqiao Xue,
   Futomi Hatano,
   Gareth Rees,
@@ -544,7 +544,7 @@
   Jacques Distler,
   Jake Archibald,
   Jake Verbaten,
-  Jakub Łopuszański,
+  Jakub Łopuszański,
   Jakub Wilk,
   James Cobban,
   James Craig,
@@ -1116,7 +1116,7 @@
   "woowaEcho", <!-- https://github.com/woowaEcho-->
   Xan Gregg,
   "Xaviju", <!-- https://github.com/Xaivju -->
-  &#xc724;&#xc11d;&#xcc2c; (Channy Yun),
+  윤석찬 (Channy Yun),
   xenotheme,
   Yang Chen,
   Yann Gouffon,

sections/browsers.include

@@ -2665,7 +2665,7 @@
   "{{SecurityError}}" {{DOMException}}.
 
   When the <dfn method for="History"><code>back()</code></dfn> method is invoked, the user
-  agent must <a>traverse the history by a delta</a> &#x2212;1. If this <code>History</code>
+  agent must <a>traverse the history by a delta</a> −1. If this <code>History</code>
   object is associated with a {{Document}} that is not <a>fully active</a>,
   invoking must instead throw a "{{SecurityError}}" {{DOMException}}.
 

sections/editing.include

@@ -324,8 +324,8 @@
     <img src="images/focus-tree.png" alt="" width="800" height="450" />
 
     If the widget with <a>focus</a> in this example was the text field in the dialog box, then key
-    input would be channeled from the graphical system to &#x2460; the Web browser, then to &#x2461;
-    the tab, then to &#x2462; the dialog, and finally to &#x2463; the text field.
+    input would be channeled from the graphical system to ① the Web browser, then to ②
+    the tab, then to ③ the dialog, and finally to ④ the text field.
   </div>
 
   Keyboard <em>events</em> are always targeted at this <a>focused</a> element.
@@ -1902,17 +1902,17 @@
 
   <div class="example">
     As an example of problems that occur if the default ''normal'' value is used instead, consider
-    the case of the user typing "<kbd>yellow&#x2423;&#x2423;ball</kbd>", with two spaces (here
-    represented by "&#x2423;") between the words. With the editing rules in place for the default
+    the case of the user typing "<kbd>yellow␣␣ball</kbd>", with two spaces (here
+    represented by "␣") between the words. With the editing rules in place for the default
     value of 'white-space' (''normal''), the resulting markup will either consist of
     "<samp>yellow&amp;nbsp;&nbsp;ball</samp>" or "<samp>yellow&nbsp;&amp;nbsp;ball</samp>"; i.e.,
     there will be a non-breaking space between the two words in addition to the regular space. This
     is necessary because the ''normal'' value for 'white-space' requires adjacent regular spaces to be
     collapsed together.
 
-    In the former case, "<samp>yellow&#x237D;</samp>" might wrap to the next line ("&#x237D;"
+    In the former case, "<samp>yellow⍽</samp>" might wrap to the next line ("⍽"
     being used here to represent a non-breaking space) even though "<samp>yellow</samp>" alone might
-    fit at the end of the line; in the latter case, "<samp>&#x237D;ball</samp>", if wrapped to the
+    fit at the end of the line; in the latter case, "<samp>⍽ball</samp>", if wrapped to the
     start of the line, would have visible indentation from the non-breaking space.
 
     When 'white-space' is set to ''pre-wrap'', however, the editing rules will instead simply put
@@ -3389,7 +3389,7 @@
   "<code>none</code>". It is updated by the user agent
   as described in the steps below.
 
-  User agents must, as soon as the drag operation is <a>initiated</a> and every 350ms (&#xB1;200ms) thereafter for as long as the drag
+  User agents must, as soon as the drag operation is <a>initiated</a> and every 350ms (±200ms) thereafter for as long as the drag
   operation is ongoing, <a>queue a task</a> to perform the following steps in sequence:
 
   <ol>
@@ -3773,23 +3773,23 @@
       <tr>
         <td><dfn event for="global"><code>dragstart</code></dfn></td>
         <td><a>Source node</a></td>
-        <td>&#x2713; Cancelable</td>
+        <td>✓ Cancelable</td>
         <td><a>Read/write mode</a>
         <td>"<code>none</code>"</td>
         <td>Initiate the drag-and-drop operation</td>
       </tr>
       <tr>
         <td><dfn event for="global"><code>drag</code></dfn></td>
         <td><a>Source node</a></td>
-        <td>&#x2713; Cancelable</td>
+        <td>✓ Cancelable</td>
         <td><a>Protected mode</a>
         <td>"<code>none</code>"</td>
         <td>Continue the drag-and-drop operation</td>
       </tr>
       <tr>
         <td><dfn event for="global"><code>dragenter</code></dfn></td>
         <td><a>Immediate user selection</a> or <a href="#the-body-element">the <code>body</code> element</a></td>
-        <td>&#x2713; Cancelable</td>
+        <td>✓ Cancelable</td>
         <td><a>Protected mode</a>
         <td>Based on {{DataTransfer/effectAllowed}} value</td>
         <td>Reject <a>immediate user selection</a> as potential <a>target element</a></td>
@@ -3813,15 +3813,15 @@
       <tr>
         <td><dfn event for="global"><code>dragover</code></dfn></td>
         <td><a>Current target element</a></td>
-        <td>&#x2713; Cancelable</td>
+        <td>✓ Cancelable</td>
         <td><a>Protected mode</a>
         <td>Based on {{DataTransfer/effectAllowed}} value</td>
         <td>Reset the <a>current drag operation</a> to "none"</td>
       </tr>
       <tr>
         <td><dfn event for="global"><code>drop</code></dfn></td>
         <td><a>Current target element</a></td>
-        <td>&#x2713; Cancelable</td>
+        <td>✓ Cancelable</td>
         <td><a>Read-only mode</a>
         <td><a>Current drag operation</a></td>
         <td>Varies</td>

sections/infrastructure.include

@@ -4768,7 +4768,7 @@ interface NoncedElement {
          <a>StructuredSerializeInternal</a>(<var>buffer</var>, <var>forStorage</var>,
          <var>memory</var>).
 
-      3. Assert&#x200b;: <var>bufferSerialized</var>.\[[Type]] is "ArrayBuffer".
+      3. Assert: <var>bufferSerialized</var>.\[[Type]] is "ArrayBuffer".
 
       4. If <var>value</var> has a \[[DataView]] internal slot, then set <var>serialized</var> to
          { \[[Type]]: "ArrayBufferView", \[[Constructor]]: "DataView", \[[ArrayBufferSerialized]]:
@@ -4777,7 +4777,7 @@ interface NoncedElement {
 
       5. Otherwise:
 
-         1. Assert&#x200b;: <var>value</var> has a \[[TypedArrayName]] internal slot.
+         1. Assert: <var>value</var> has a \[[TypedArrayName]] internal slot.
 
          2. Set <var>serialized</var> to { \[[Type]]: "ArrayBufferView", \[[Constructor]]:
             <var>value</var>.\[[TypedArrayName]], \[[ArrayBufferSerialized]]: <var>bufferSerialized</var>,
@@ -4995,7 +4995,7 @@ o.myself = o;</pre>
 
   5. If <var>serialized</var> contains a \[[TransferConsumed]] field, then:
 
-     1. Assert&#x200b;: <var>serialized</var>.\[[TransferConsumed]] is false. (It must be impossible to
+     1. Assert: <var>serialized</var>.\[[TransferConsumed]] is false. (It must be impossible to
         get in a situation where <a>StructuredDeserialize</a> is being called multiple times on
         the same serialization, if that serialization contains transfer data holders.)
 
@@ -5179,7 +5179,7 @@ o.myself = o;</pre>
             2. Let <var>result</var> be ! <a>CreateDataProperty</a>(<var>value</var>,
                 <var>entry</var>.\[[Key]], <var>deserializedValue</var>).
 
-            3. Assert&#x200b;: <var>result</var> is true.
+            3. Assert: <var>result</var> is true.
 
       4. Otherwise:
 
@@ -5245,7 +5245,7 @@ o.myself = o;</pre>
 
      4. Otherwise:
 
-        1. Assert&#x200b;: <var>transferable</var> is a <a>platform object</a> that is
+        1. Assert: <var>transferable</var> is a <a>platform object</a> that is
             a <a>transferable object</a>.
 
         2. Let <var>interfaceName</var> be the identifier of the <a>primary interface</a>

sections/introduction.include

@@ -367,7 +367,7 @@
 
     Variables are marked up like <var>this</var>.
 
-    In an algorithm, steps in <a>synchronous sections</a> are marked with &#x231B;.
+    In an algorithm, steps in <a>synchronous sections</a> are marked with ⌛.
 
     In some cases, requirements are given in the form of lists with conditions and corresponding
     requirements. In such cases, the requirements that apply to a condition are always the first
@@ -492,7 +492,7 @@
   <a lt="attribute">Attributes</a> are placed inside the start tag, and consist of a
   <a lt="attribute names">name</a> and a <a lt="attribute values">value</a>, separated by an
   "<code>=</code>" character. The attribute value can remain <a>unquoted</a> if it doesn't contain
-  [=space characters=] or any of <code>"</code> <code>'</code> <code>&#x60;</code> <code>=</code>
+  [=space characters=] or any of <code>"</code> <code>'</code> <code>`</code> <code>=</code>
   <code>&lt;</code> or <code>&gt;</code>. Otherwise, it has to be quoted using either single or
   double quotes. The value, along with the "<code>=</code>" character, can be omitted altogether if
   the value is the empty string.
@@ -525,28 +525,28 @@
         <li class="t1">
           <{head}>
           <ul>
-            <li class="t3"><code>#text</code>: <span>&#x23CE;&#x2423;&#x2423;</span></li>
+            <li class="t3"><code>#text</code>: <span>⏎␣␣</span></li>
             <li class="t1">
               <{title}>
               <ul>
                 <li class="t3"><code>#text</code>: <span>Sample page</span></li>
               </ul>
             </li>
-            <li class="t3"><code>#text</code>: <span>&#x23CE;&#x2423;</span></li>
+            <li class="t3"><code>#text</code>: <span>⏎␣</span></li>
           </ul>
         </li>
-        <li class="t3"><code>#text</code>: <span>&#x23CE;&#x2423;</span></li>
+        <li class="t3"><code>#text</code>: <span>⏎␣</span></li>
         <li class="t1">
           <{body}>
           <ul>
-            <li class="t3"><code>#text</code>: <span>&#x23CE;&#x2423;&#x2423;</span></li>
+            <li class="t3"><code>#text</code>: <span>⏎␣␣</span></li>
             <li class="t1">
               <{h1}>
               <ul>
                 <li class="t3"><code>#text</code>: <span>Sample page</span></li>
               </ul>
             </li>
-            <li class="t3"><code>#text</code>: <span>&#x23CE;&#x2423;&#x2423;</span></li>
+            <li class="t3"><code>#text</code>: <span>⏎␣␣</span></li>
             <li class="t1">
               <{p}>
               <ul>
@@ -560,9 +560,9 @@
                 <li class="t3"><code>#text</code>: <span> sample.</span></li>
               </ul>
             </li>
-            <li class="t3"><code>#text</code>: <span>&#x23CE;&#x2423;&#x2423;</span></li>
+            <li class="t3"><code>#text</code>: <span>⏎␣␣</span></li>
             <li class="t8"><code>#comment</code>: <span> this is a comment </span></li>
-            <li class="t3"><code>#text</code>: <span>&#x23CE;&#x2423;&#x23CE;</span></li>
+            <li class="t3"><code>#text</code>: <span>⏎␣⏎</span></li>
           </ul>
         </li>
       </ul>
@@ -574,7 +574,7 @@
   {{Text}} node between them.
 
   There are many more {{Text}} nodes in the DOM tree than one would initially expect, because the
-  source contains a number of spaces (represented here by "&#x2423;") and line breaks ("&#x23CE;")
+  source contains a number of spaces (represented here by "␣") and line breaks ("⏎")
   that all end up as {{Text}} nodes in the DOM. However, for historical reasons not all of the
   spaces and line breaks in the original markup appear in the DOM. In particular, all the white
   space before <{head}> start tag ends up being dropped silently, and all the white space after

sections/rendering.include

@@ -2131,8 +2131,8 @@ Rendering {#rendering}
     <pre highlight="javascript">alert('\u05DC\u05DE\u05D3 HTML \u05D4\u05D9\u05D5\u05DD!')</pre>
 
     ...would always result in a message reading
-        "<bdo lang="" dir="rtl">&#x05DC;&#x05DE;&#x05D3;&nbsp;LMTH&nbsp;&#x05D4;&#x05D9;&#x05D5;&#x05DD;!</bdo>"
-    (not "<bdo lang="" dir="ltr">&#x05D3;&#x05DE;&#x05DC;&nbsp;HTML&nbsp;&#x05DD;&#x05D5;&#x05D9;&#x05D4;!</bdo>"),
+        "<bdo lang="" dir="rtl">למד LMTH היום!</bdo>"
+    (not "<bdo lang="" dir="ltr">דמל HTML םויה!</bdo>"),
     regardless of the language of the user agent interface or the direction of the page or any of
     its elements.
   </div>
@@ -2150,10 +2150,10 @@ Rendering {#rendering}
 
     When the user enters "<kbd>Kitty</kbd>", the user agent would alert
     "<samp>Kitty! Ok, Fred, Kitty, and Wilma will get the car.</samp>". However, if the user enters
-    "<kbd dir="rtl" lang="ar">&#x644;&#x627;&nbsp;&#x623;&#x641;&#x647;&#x645;</kbd>", then the
+    "<kbd dir="rtl" lang="ar">لا أفهم</kbd>", then the
     bidirectional algorithm will determine that the direction of the paragraph is right-to-left, and
     so the output will be the following unintended mess:
-    "<samp lang=""><bdo dir="rtl">&#x644;&#x627;&nbsp;&#x623;&#x641;&#x647;&#x645;!&nbsp;derF&nbsp;,kO,&nbsp;&#x644;&#x627;&nbsp;&#x623;&#x641;&#x647;&#x645;,&nbsp;rac&nbsp;eht&nbsp;teg&nbsp;lliw&nbsp;amliW&nbsp;dna.</bdo></samp>"
+    "<samp lang=""><bdo dir="rtl">لا أفهم! derF ,kO, لا أفهم, rac eht teg lliw amliW dna.</bdo></samp>"
 
     To force an alert that starts with user-provided text (or other text of unknown directionality)
     to render left-to-right, the string can be prefixed with a U+200E LEFT-TO-RIGHT MARK character: