keyattribute or the
codeattribute instead of
shiftKey. To detect any other modifier keys use the
Web standards are always changing and it should come as no surprise that even the modest Keyboard Event API has received a few updates. The good news is that it’s been improved for the betterment of all developers.
Browser support for keyboards has traditionally relied on three ad-hoc attributes, keyCode, charCode, and UIEvent's which.
The biggest source of confusion for me has always been trying to figure out which of the 3 ways to get the key code was the correct way. For God’s sake, I just want to know which key is being pressed!
I’m glad to report back that the W3C has deprecated all 3 of these attributes
in the DOM Level 3 specification and they now recommended using
key attribute returns a human-readable string for both printable and
non-printable control characters. And the
code attribute returns a string
representing the physical position of the key on your particular keyboard.
Warning! The keypress event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type.
Another surprising change in the DOM Level 3 specification is that the
keypress event has been deprecated. This is a great design choice because:
keypressevent and the
keypressevent behaves almost exactly like the
keydownevent except that the former does not receive control characters.
Finally, it’s now possible to detect modifier keys besides
Shift. With the
detect modifier keys such as
NumLock and other OS specific
Win for Internet Explorer.