minor

2-ui/3-event-details/5-keyboard-events/2-check-sync-keydown/solution.md

@@ -1,6 +1,6 @@
 
 We should use two handlers: `document.onkeydown` and `document.onkeyup`.
 
-The set `pressed` should keep currently pressed keys.
+Let's create a set `pressed = new Set()` to keep currently pressed keys.
 
 The first handler adds to it, while the second one removes from it. Every time on `keydown` we check if we have enough keys pressed, and run the function if it is so.

2-ui/3-event-details/5-keyboard-events/article.md

@@ -2,7 +2,7 @@
 
 Before we get to keyboard, please note that on modern devices there are other ways to "input something". For instance, people use speech recognition (especially on mobile devices) or copy/paste with the mouse.
 
-So if we want to track any input into an `<input>` field, then keyboard events are not enough. There's another event named `input` to handle changes of an `<input>` field, by any means. And it may be a better choice for such task. We'll cover it later in the chapter <info:events-change-input>.
+So if we want to track any input into an `<input>` field, then keyboard events are not enough. There's another event named `input` to track changes of an `<input>` field, by any means. And it may be a better choice for such task. We'll cover it later in the chapter <info:events-change-input>.
 
 Keyboard events should be used when we want to handle keyboard actions (virtual keyboard also counts). For instance, to react on arrow keys `key:Up` and `key:Down` or hotkeys (including combinations of keys).
 
@@ -30,7 +30,7 @@ The `keydown` events happens when a key is pressed down, and then `keyup` -- whe
 
 The `key` property of the event object allows to get the character, while the `code` property of the event object allows to get the "physical key code".
 
-For instance, the same key `key:Z` can be pressed with or without `Shift`. That gives us two different characters: lowercase `z` and uppercase `Z`.
+For instance, the same key `key:Z` can be pressed with or without `key:Shift`. That gives us two different characters: lowercase `z` and uppercase `Z`.
 
 The `event.key` is exactly the character, and it will be different. But `event.code` is the same:
 
@@ -52,7 +52,7 @@ For instance:
 
 There are several widespread keyboard layouts, and the specification gives key codes for each of them.
 
-See [alphanumeric section of the spec](https://www.w3.org/TR/uievents-code/#key-alphanumeric-section) for more codes, or just try the [teststand](#keyboard-test-stand) above.
+Read the [alphanumeric section of the spec](https://www.w3.org/TR/uievents-code/#key-alphanumeric-section) for more codes, or just press a key in the [teststand](#keyboard-test-stand) above.
 ```
 
 ```warn header="Case matters: `\"KeyZ\"`, not `\"keyZ\"`"
@@ -61,9 +61,7 @@ Seems obvious, but people still make mistakes.
 Please evade mistypes: it's `KeyZ`, not `keyZ`. The check like `event.code=="keyZ"` won't work: the first letter of `"Key"` must be uppercase.
 ```
 
-
-What if a key does not give any character? For instance, `key:Shift` or `key:F1` or others. For those keys `event.key` is approximately the same as `event.code`:
-
+What if a key does not give any character? For instance, `key:Shift` or `key:F1` or others. For those keys, `event.key` is approximately the same as `event.code`:
 
 | Key          | `event.key` | `event.code` |
 |--------------|-------------|--------------|
@@ -73,11 +71,11 @@ What if a key does not give any character? For instance, `key:Shift` or `key:F1`
 
 Please note that `event.code` specifies exactly which key is pressed. For instance, most keyboards have two `key:Shift` keys: on the left and on the right side. The `event.code` tells us exactly which one was pressed, and `event.key` is responsible for the "meaning" of the key: what it is (a "Shift").
 
-Let's say, we want to handle a hotkey: `key:Ctrl+Z` (or `key:Cmd+Z` for Mac). Most text editors hook the "Undo" action on it. We can set a listener on `keydown` and check which key is pressed -- to detect when we have the hotkey.
+Let's say, we want to handle a hotkey: `key:Ctrl+Z` (or `key:Cmd+Z` for Mac). Most text editors hook the "Undo" action on it. We can set a listener on `keydown` and check which key is pressed.
 
 There's a dilemma here: in such a listener, should we check the value of `event.key` or `event.code`?
 
-On one hand, the value of `event.key` changes depending on the language. If the visitor has several languages in OS and switches between them, the same key gives different characters. So it makes sense to check `event.code`, it's always the same.
+On one hand, the value of `event.key` is a character, it changes depending on the language. If the visitor has several languages in OS and switches between them, the same key gives different characters. So it makes sense to check `event.code`, it's always the same.
 
 Like this:
 
@@ -89,9 +87,9 @@ document.addEventListener('keydown', function(event) {
 });
 ```
 
-On the other hand, there's a problem with `event.code`. For different keyboard layouts, the same key may have different labels (letters).
+On the other hand, there's a problem with `event.code`. For different keyboard layouts, the same key may have different characters.
 
-For example, here are US layout ("QWERTY") and German layout ("QWERTZ") under it (courtesy of Wikipedia):
+For example, here are US layout ("QWERTY") and German layout ("QWERTZ") under it (from Wikipedia):
 
 ![](us-layout.svg)
 
@@ -99,14 +97,21 @@ For example, here are US layout ("QWERTY") and German layout ("QWERTZ") under it
 
 For the same key, US layout has "Z", while German layout has "Y" (letters are swapped).
 
-So, `event.code` will equal `KeyZ` for people with German layout when they press "Y".
+Literally, `event.code` will equal `KeyZ` for people with German layout when they press `key:Y`.
 
-That sounds odd, but so it is. The [specification](https://www.w3.org/TR/uievents-code/#table-key-code-alphanumeric-writing-system) explicitly mentions such behavior.
+If we check `event.code == 'KeyZ'` in our code, then for people with German layout such test will pass when they press `key:Y`.
 
-- `event.code` has the benefit of staying always the same, bound to the physical key location, even if the visitor changes languages. So hotkeys that rely on it work well even in case of a language switch.
-- `event.code` may match a wrong character for unexpected layout. Same letters in different layouts may map to different physical keys, leading to different codes. Luckily, that happens only with several codes, e.g. `keyA`, `keyQ`, `keyZ` (as we've seen), and doesn't happen with special keys such as `Shift`. You can find the list in the [specification](https://www.w3.org/TR/uievents-code/#table-key-code-alphanumeric-writing-system).
+That sounds really odd, but so it is. The [specification](https://www.w3.org/TR/uievents-code/#table-key-code-alphanumeric-writing-system) explicitly mentions such behavior.
 
-So, to reliably track layout-dependent characters, `event.key` may be a better way.
+So, `event.code` may match a wrong character for unexpected layout. Same letters in different layouts may map to different physical keys, leading to different codes. Luckily, that happens only with several codes, e.g. `keyA`, `keyQ`, `keyZ` (as we've seen), and doesn't happen with special keys such as `Shift`. You can find the list in the [specification](https://www.w3.org/TR/uievents-code/#table-key-code-alphanumeric-writing-system).
+
+To reliably track layout-dependent characters, `event.key` may be a better way.
+
+On the other hand, `event.code` has the benefit of staying always the same, bound to the physical key location, even if the visitor changes languages. So hotkeys that rely on it work well even in case of a language switch.
+
+Do we want to handle layout-dependant keys? Then `event.key` is the way to go.
+
+Or we want a hotkey to work even after a language switch? Then `event.code` may be better.
 
 ## Auto-repeat
 
@@ -140,7 +145,7 @@ function checkPhoneKey(key) {
 <input *!*onkeydown="return checkPhoneKey(event.key)"*/!* placeholder="Phone, please" type="tel">
 ```
 
-Please note that special keys like `key:Backspace`, `key:Left`, `key:Right`, `key:Ctrl+V` do not work in the input. That's a side-effect of the strict filter `checkPhoneKey`.
+Please note that special keys, such as `key:Backspace`, `key:Left`, `key:Right`, `key:Ctrl+V`, do not work in the input. That's a side-effect of the strict filter `checkPhoneKey`.
 
 Let's relax it a little bit:
 
@@ -165,8 +170,6 @@ In the past, there was a `keypress` event, and also `keyCode`, `charCode`, `whic
 
 There were so many browser incompatibilities while working with them, that developers of the specification had no way, other than deprecating all of them and creating new, modern events (described above in this chapter). The old code still works, as browsers keep supporting them, but there's totally no need to use those any more.
 
-There was a time when this chapter included their detailed description. But, as of now, browsers support modern events, so it was removed and replaced with more details about the modern event handling.
-
 ## Summary
 
 Pressing a key always generates a keyboard event, be it symbol keys or special keys like `key:Shift` or `key:Ctrl` and so on. The only exception is `key:Fn` key that sometimes presents on a laptop keyboard. There's no keyboard event for it, because it's often implemented on lower level than OS.