5 ms·

TL;DR. Don't use keypress, it's deprecated. Don't use 'keyCode', 'which', 'char' which are all deprecated. Do use 'key' Another issue I run into is forms that

TL;DR. Don't use keypress, it's deprecated. Don't use 'keyCode', 'which', 'char' which are all deprecated. Do use 'key' Another issue I run into is forms that dismiss via keydown and escape. I type in Japanese which means I'm using an IME. An IME, or at least the Japanese IME, you type characters and they appear with possible completions. They haven't actually been given to the app yet. Pressing Escape cancels the completions. But webpages that cancel some model form dialog via escape means that if I press ESC to cancel IME completion (which is common) I also cancel the dialog and lose all input had previously entered into the form. I'd think this would been solved at the browser level, if the IME is active then don't pass keys to the app but for probably valid reasons that's not what happens. TL;DR don't use escape to cancel a model form! edit: apparently there's the 'isComposting' property on the KeyboardEvent to find out if the user is currently using the IME https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/isComposing https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...

Vinnl 6y ago
Thanks, going to add that to a modal today.
tkainrad 6y ago
Not sure if I agree with this summary of my article. For most web apps with relatively few keyboard shortcuts, I would actually recommend to use keypress. keyCode/which/charCode work when used with keypress. The article mentions an open-source example that does it this way and works fine on international layouts: Discourse
- greggman3 6y ago
  Well, maybe you should go edit MDN because it has a giant red "DEPRECATED" at the top of keypress https://developer.mozilla.org/en-US/docs/Web/API/Document/keypress_event https://developer.mozilla.org/en-US/docs/Web/API/Document/ke...
  - tkainrad 6y ago
    Never said it wasn't deprecated. It still works much better than using keydown with keycode. For most apps and layouts, it's a sufficient solution.
    - runarberg 6y ago
      What works best is to use `keydown`[1] with `keyboardEvent.key`[2]. Chrome took a while to implement `keyboardEvent.key` and I’m guessing that delay hindered adoption, but for the past few years (since the 5 year old Chrome 51) it is objectively the best—and arguably the only robust—way to figure out which key the user typed. 1: https://developer.mozilla.org/en-US/docs/Web/API/Element/keydown_event https://developer.mozilla.org/en-US/docs/Web/API/Element/key... 2: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
apiep 6y ago
Or even better, do not put form in a closable dialog / "things"
bbarn 6y ago
Question then - what do you use functionally to replace "Escape" in your daily use? As a native English-speaking engineer, the escape button has a history of doing exactly what you're suggesting it not do going back to the beginning of computing.
- int_19h 6y ago
  The standard behavior of Esc is to abort the current interaction - which is not the same as closing the dialog. For example, if you have a dialog with a drop-down list, and open that list, Esc should close it, not the whole dialog. In this scenario, the "current interaction" is IME input. The bug is that the page intercepts Esc keypresses intended to be handled by it.
  - wccrawford 6y ago
    I haven't checked in a while, but I'm pretty sure the dialog has no idea that the IME is active or not. So the dialog can't handle that situation, and the browser isn't handling it either. The IME/browser should not send escape to the page when canceling an IME selection.
- runarberg 6y ago
  First of all. Don’t put long forms (i.e. more then a couple of inputs; including checkboxes) in a single dialog modal. Second do listen for keypresses on the dialog it self (not window) so that hitting esc on e.g. the URL bar (or the developer console) has no effect on the dialog it self. And thirdly—as parent states—don’t use deprecated properties and listeners, i.e. use `keydown` and `event.key`. If you follow these three rules feel free to use the esc to close the dialog. I just tested logging `event.key` with hiragana Mozc input device and every keydown while selecting the correct kanji registers as `Process` even cancelling the input with Esc just adds another Process keydown event. I admit it can be frustrating if you double tab Esc accidentally to close the input (second Esc will close the dialog), but that is where rule one comes in, and the accident will only cause the user a minor annoyance.

Vinnl 6y ago

Thanks, going to add that to a modal today.

tkainrad 6y ago

Not sure if I agree with this summary of my article. For most web apps with relatively few keyboard shortcuts, I would actually recommend to use keypress. keyCode/which/charCode work when used with keypress. The article mentions an open-source example that does it this way and works fine on international layouts: Discourse

greggman3 6y ago
Well, maybe you should go edit MDN because it has a giant red "DEPRECATED" at the top of keypress https://developer.mozilla.org/en-US/docs/Web/API/Document/keypress_event https://developer.mozilla.org/en-US/docs/Web/API/Document/ke...
- tkainrad 6y ago
  Never said it wasn't deprecated. It still works much better than using keydown with keycode. For most apps and layouts, it's a sufficient solution.
  - runarberg 6y ago
    What works best is to use `keydown`[1] with `keyboardEvent.key`[2]. Chrome took a while to implement `keyboardEvent.key` and I’m guessing that delay hindered adoption, but for the past few years (since the 5 year old Chrome 51) it is objectively the best—and arguably the only robust—way to figure out which key the user typed. 1: https://developer.mozilla.org/en-US/docs/Web/API/Element/keydown_event https://developer.mozilla.org/en-US/docs/Web/API/Element/key... 2: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...

apiep 6y ago

Or even better, do not put form in a closable dialog / "things"

bbarn 6y ago

Question then - what do you use functionally to replace "Escape" in your daily use? As a native English-speaking engineer, the escape button has a history of doing exactly what you're suggesting it not do going back to the beginning of computing.

int_19h 6y ago
The standard behavior of Esc is to abort the current interaction - which is not the same as closing the dialog. For example, if you have a dialog with a drop-down list, and open that list, Esc should close it, not the whole dialog. In this scenario, the "current interaction" is IME input. The bug is that the page intercepts Esc keypresses intended to be handled by it.
- wccrawford 6y ago
  I haven't checked in a while, but I'm pretty sure the dialog has no idea that the IME is active or not. So the dialog can't handle that situation, and the browser isn't handling it either. The IME/browser should not send escape to the page when canceling an IME selection.
runarberg 6y ago
First of all. Don’t put long forms (i.e. more then a couple of inputs; including checkboxes) in a single dialog modal. Second do listen for keypresses on the dialog it self (not window) so that hitting esc on e.g. the URL bar (or the developer console) has no effect on the dialog it self. And thirdly—as parent states—don’t use deprecated properties and listeners, i.e. use `keydown` and `event.key`. If you follow these three rules feel free to use the esc to close the dialog. I just tested logging `event.key` with hiragana Mozc input device and every keydown while selecting the correct kanji registers as `Process` even cancelling the input with Esc just adds another Process keydown event. I admit it can be frustrating if you double tab Esc accidentally to close the input (second Esc will close the dialog), but that is where rule one comes in, and the accident will only cause the user a minor annoyance.