Open masayuki-nakano opened 4 years ago
@garykac According to the behavior of Chrome for Windows, Chrome exposes only some control character inputs even when a printable key with Ctrl
key is pressed. But I don't find the code nor the reason yet. Do you know somebody who know around it?
Today's a holiday, but I'll follow up on this tomorrow. I know how to track down more info about this.
I was unsuccessful tracking down more info on this. But I can try reaching out more broadly.
It feels like this should be generating an input
event rather than a keypress
event. Since keypress
is deprecated, we can't ask people to rely on it.
It feels like this should be generating an
input
event rather than akeypress
event. Sincekeypress
is deprecated, we can't ask people to rely on it.
I strongly disagree on this point. IMO, the spec should require what browsers need to implement in order to make web pages work as intended. @masayuki-nakano cited a web compat requirement. If the spec requires something different from what browsers need to implement to be compatible with the web, then the spec will be ignored.
I think this is a fundamental principle for web specs.
Things can be marked as deprecated or obsolete and still have non-optional, well-defined and web-compatible specification.
Currently,
keypress
event is defined as that it's fired only when a key press introduces a character.https://w3c.github.io/uievents/#event-type-keypress
However, both Chrome and Safari violates this rule, but some web apps may depend on control character inputting
keypress
. So, there should be clearer and not breaking existing web apps rule.