Further fixes to keydown vs. keyup for close requests

The original text was written based on the misunderstanding that keyup was the correct event. A small patch was made in d785cbe, but it was not complete; other parts of the text were still wrong, or overly-complex. This rewrites the relevant requirements and examples to be clearer, now that we know keydown is correct.

Closes #10523.

Author: domenic

source

@@ -82056,26 +82056,22 @@ body { display:none }
     <p>Fire any relevant events, per <cite>UI Events</cite> or other relevant specifications.
     <ref>UIEVENTS</ref></p>
 
-    <p class="example">An example of relevant events in the <cite>UI Events</cite> model would be
-    the <code data-x="event-keydown">keydown</code> and <code data-x="event-keyup">keyup</code>
-    sequence that <cite>UI Events</cite> <a
+    <p class="example">An example of a relevant event in the <cite>UI Events</cite> model would be
+    the <code data-x="event-keydown">keydown</code>  event that <cite>UI Events</cite> <a
     href="https://w3c.github.io/uievents/#events-keyboard-event-order">suggests</a> firing when the
     user presses the <kbd>Esc</kbd> key on their keyboard. On most platforms with keyboards, this
     is treated as a <span>close request</span>, and so would trigger these <span>close request
     steps</span>.</p>
 
     <p class="example">An example of relevant events that are outside of the model given in
     <cite>UI Events</cite> would be assistive technology synthesizing an <kbd>Esc</kbd> <code
-    data-x="event-keydown">keydown</code> and <code data-x="event-keyup">keyup</code> sequence when
-    the user sends a <span>close request</span> by using a dismiss gesture.</p>
+    data-x="event-keydown">keydown</code> event when the user sends a <span>close request</span> by
+    using a dismiss gesture.</p>
    </li>
 
-   <li><p>Let <var>event</var> be null if no such events are fired, or the <code>Event</code> object
-   representing one of the fired events otherwise. If multiple events are fired, which one is chosen
-   is <span>implementation-defined</span>, except that if <code
-   data-x="event-keydown">keydown</code> and <code data-x="event-keyup">keyup</code> events were
-   fired for the <kbd>Esc</kbd> key, the user agent must pick the <code
-   data-x="event-keydown">keydown</code> event.</p></li>
+   <li><p>Let <var>event</var> be null if no such events are fired, or the <code>Event</code>
+   object representing one of the fired events otherwise. If multiple events are fired, which one
+   is chosen is <span>implementation-defined</span>.</p></li>
 
    <li><p>If <var>event</var> is not null, and its <span>canceled flag</span> is set, then
    return.</p></li>
@@ -82100,10 +82096,14 @@ body { display:none }
 
   </div>
 
+  <p>On platforms where pressing the <kbd>Esc</kbd> key is interpreted as a <span>close
+  request</span>, the user agent must interpret the key being pressed <em>down</em> as the close
+  request, instead of the key being released. Thus, in the above algorithm, the "relevant events"
+  that are fired must be the single <code data-x="event-keydown">keydown</code> event.</p>
+
   <p class="example">On platforms where <kbd>Esc</kbd> is the <span>close request</span>, the user
-  agent will first fire an appropriately-initialized <code data-x="event-keydown">keydown</code> and
-  <code data-x="event-keyup">keyup</code> event sequence. If the web developer cancels the <code
-  data-x="event-keyup">keyup</code> event by calling <code
+  agent will first fire an appropriately-initialized <code data-x="event-keydown">keydown</code>
+  event. If the web developer cancels the event by calling <code
   data-x="dom-Event-preventDefault">preventDefault()</code>, then nothing further happens. But if
   the event fires without being canceled, then the user agent proceeds to <span>process close
   watchers</span>.</p>