Review whether key, code etc should be present in legacy keypress events

[drwez]

At present the spec (see https://www.w3.org/TR/uievents/#event-type-keypress) lists key, code, location, as present and set to non-trivial values in keypress events.

Since keypress events describe character-input resulting from keyboard activity (i.e. keydown and keyup), and since the event is deprecated by input for this purpose, it's not clear why it should have non-trivial values set for these newer fields.

[drwez]

@garykac Any thoughts on this topic? Do you recall why these fields were specified on the legacy event in the first place?

[garykac]

I don't remember the details, but when we added key and code, we didn't know which transition would happen first:

• Would devs stop using keypress and start using input/beforeinput
• Would devs stop using keyCode/charCode and start using key/code

To hedge against this uncertainty, having defined key and code values for keypress was the safest approach.

However, I don't think we ever had a serious discussion about whether we should purposefully leave these attribute unset in the KeyboardEvent for keypress. It was assumed that they would follow the values in the corresponding keydown/keyup events.

[drwez]

Thanks @garykac - unfortunately as has been discussed earlier, it doesn't make sense to leave the key attribute set to the value from the corresponding keydown/keyup in the case of non-BMP characters, unless we assume that implementations only generate a single keypress per-keydown even for those - which has not historically been the case.

Whether it makes sense to set key in a keypress event therefore depends on the discussion in issue 346

[masayuki-nakano]

input (and beforeinput) are fired only in editable content, and keypress indicates that the "key press" introduces a text input. Therefore, I think that .key of keypress may be required by some web apps which handle text input without editable element.

Additionally, it's already spent a while after shipping the new KeyboardEvent attributes. Therefore, it may be risky to change keypress events attributes too.

[drwez]

@masayuki-nakano your observation re the distinction between input and keypress behaviour in terms of which content they will "fire" for suggests that perhaps we should actually be specifying keypress as more than just a legacy-compatability consideration, then?

[masayuki-nakano]

I'm not sure. Basically, keydown should be used instead of keypress. However, KeyboardEvent does not have attribute whether it will introduce a text input.

• no way to distinguish printable key values from non-printable #264
• keydown event should have an attribute which is set to true when it's followed by a beforeinput or keypress event? #179

I think that there should be new attribute instead of making keypress event more usable for inputs from keyboard.

On the other hand, some text input on macOS and Linux is represented only with beforeinput in editable area (e.g., bug 1520983) and web apps listens only to keypress events are not IME-aware, that's very bad design for IME users. Therefore, working a lot around KeyboardEvent may lead inaccessible web-apps development...