According to MDN, we should most definitely not be using the .keyCode property. It is deprecated:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
On W3 school, this fact is played down and there is only a side note saying that .keyCode
is provided for compatibility only and that the latest version of the DOM Events Specification recommend using the .key
property instead.
The problem is that .key
is not supported by browsers, so what should we using? Is there something I'm missing?
You have three ways to handle it, as it's written on the link you shared.
if (event.key !== undefined) {
} else if (event.keyIdentifier !== undefined) {
} else if (event.keyCode !== undefined) {
}
you should contemplate them, that's the right way if you want cross browser support.
It could be easier if you implement something like this.
var dispatchForCode = function(event, callback) {
var code;
if (event.key !== undefined) {
code = event.key;
} else if (event.keyIdentifier !== undefined) {
code = event.keyIdentifier;
} else if (event.keyCode !== undefined) {
code = event.keyCode;
}
callback(code);
};
In addition that all of keyCode, which, charCode and keyIdentifier are deprecated :
charCode
and keyIdentifier
are non-standard features.
keyIdentifier
is removed as of Chrome 54 and Opera 41.0
keyCode
returns 0, on keypress event with normal characters on FF.
The key property :
readonly attribute DOMString key
Holds a key attribute value corresponding to the key pressed
As of the time of this writing, the key
property is supported by all major browsers as of : Firefox 52, Chrome 55, Safari 10.1, Opera 46. Except Internet Explorer 11 which has :
non-standard key identifiers and incorrect behavior with AltGraph. More info
If that is important and/or backward compatibility is, then you can use feature detection as in the following code :
Notice that the key
value is different from keyCode
or which
properties in that : it contains the name of the key not its code. If your program needs characters' codes then you can make use of charCodeAt()
.
For single printable characters you can use charCodeAt()
, if you're dealing with keys whose values contains multiple characters like ArrowUp
chances are : you are testing for special keys and take actions accordingly. So try implementing a table of keys' values and their corresponding
codes charCodeArr["ArrowUp"]=38
, charCodeArr["Enter"]=13
,charCodeArr[Escape]=27
... and so on, please take a look at Key Values and their corresponding codes
if(e.key!=undefined){
var characterCode = charCodeArr[e.key] || e.key.charCodeAt(0);
}else{
/* As @Leonid suggeted */
var characterCode = e.which || e.charCode || e.keyCode || 0;
}
/* ... code making use of characterCode variable */
May be you want to consider forward compatibility i.e use the legacy properties while they're available, and only when dropped switch to the new ones :
if(e.which || e.charCode || e.keyCode ){
var characterCode = e.which || e.charCode || e.keyCode;
}else if (e.key!=undefined){
var characterCode = charCodeArr[e.key] || e.key.charCodeAt(0);
}else{
var characterCode = 0;
}
See also : the KeyboardEvent.code
property docs and some more details in this answer.
TLDR: I'd suggest that you should use the new event.key
and event.code
properties instead of the legacy ones. IE and Edge have support for these properties, but don't support the new key names yet. For them, there is a small polyfill which makes them output the standard key/code names:
https://github.com/shvaikalesh/shim-keyboard-event-key
I came to this question searching for the reason of the same MDN warning as OP. After searching some more, the issue with keyCode
becomes more clear:
The problem with using keyCode
is that non-English keyboards can produce different outputs and even keyboards with different layouts can produce inconsistent results. Plus, there was the case of
If you read the W3C spec:
https://www.w3.org/TR/uievents/#interface-keyboardevent
In practice, keyCode and charCode are inconsistent across platforms and even the same implementation on different operating systems or using different localizations.
It goes into some depth describing what was wrong with keyCode
:
https://www.w3.org/TR/uievents/#legacy-key-attributes
These features were never formally specified and the current browser implementations vary in significant ways. The large amount of legacy content, including script libraries, that relies upon detecting the user agent and acting accordingly means that any attempt to formalize these legacy attributes and events would risk breaking as much content as it would fix or enable. Additionally, these attributes are not suitable for international usage, nor do they address accessibility concerns.
So, after establishing the reason why the legacy keyCode was replaced, let's look at what you need to do today:
- All modern browsers support the new properties (
key
and code
).
- IE and Edge support an older version of the spec, which has different names for some keys. You can use a shim for it: https://github.com/shvaikalesh/shim-keyboard-event-key (or roll your own - it's rather small anyways)
- Edge has fixed this bug in the latest release (probably will be released in Apr 2018) - https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8860571/
- Refer to the list of event keys you can use: https://www.w3.org/TR/uievents-key/
MDN has already provided a solution:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode
window.addEventListener("keydown", function (event) {
if (event.defaultPrevented) {
return; // Should do nothing if the default action has been cancelled
}
var handled = false;
if (event.key !== undefined) {
// Handle the event with KeyboardEvent.key and set handled true.
} else if (event.keyIdentifier !== undefined) {
// Handle the event with KeyboardEvent.keyIdentifier and set handled true.
} else if (event.keyCode !== undefined) {
// Handle the event with KeyboardEvent.keyCode and set handled true.
}
if (handled) {
// Suppress "double action" if event handled
event.preventDefault();
}
}, true);
For instance if you want to detect whether the "Enter"-key was clicked or not:
Instead of
event.keyCode === 13
Do it like
event.key === 'Enter'