search

w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
147 stars 52 forks source link

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

Open drwez opened 1 year ago

drwez commented 1 year ago

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 commented 1 year ago

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

garykac commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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.

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...