apparently keyCode is obsolete, and has been for a while

[Pomax]

I just read through https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode which highlights that event.keyCode is actually obsolete and has been replaced by event.code instead, with https://w3c.github.io/uievents/#idl-keyboardeventinit having this to say:

Legacy keyboard event implementations include three additional attributes, keyCode, charCode, and which. The keyCode attribute indicates a numeric value associated with a particular key on a computer keyboard, while the charCode attribute indicates the ASCII value of the character associated with that key (which might be the same as the keyCode value) and is applicable only to keys that produce a character value.

In practice, keyCode and charCode are inconsistent across platforms and even the same implementation on different operating systems or using different localizations. This specification does not define values for either keyCode or charCode, or behavior for charCode. In conforming UI Events implementations, content authors can instead use key and code.

It might be necessary to update the code to make use of .code instead, in order to keep up with the DOM spec.

[i-like-robots]

Thanks for your query @Pomax. Hopefully this has not caused anybody any issues - these things do tend to unofficially converge with specced features... innerText springs to mind as that was eventually standardised!

[Pomax]

I suspect most browsers still support it because it would break all the things if they didn't, but probably worth updating for a next version =)

The .innerText property is a good example too. but my favourite most recent one I can remember is .outerHTML which became standardized when no one was looking. It makes life (for some of us) so much easier.

[i-like-robots]

I tried switching from keyCode to code when investigating #84 but unfortunately it doesn't seem to have been implemented in IE nor yet in Edge.

[Pomax]

boo =( (thanks Edge team...)

[ajmas]

The key seems to be the better attribute, based on: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key .

If we use delimiterChars, then we could do something like:

['Tab', 'Enter', ',']

But that has the risk of causing issues where we really want multi-character delimiters, if there really is a use-case for them.

Whatever solution we come up with, we need to consider:

• Impact on typing, in the handleKeyDown method
• Impact on pasting, in the handlePaste method
• Whether there is a need for multi-character delimiters, which don't reference keys.

[i-like-robots]

I think the separation of delimiter keys (IE. pressing tab or enter) and delimiter characters is OK, so long as it is documented clearly. Using KeyboardEvent.key definitely seems like a good step to make in the next major version.

[ajmas]

Opened issue #94, based on an issue discovered on Android Chrome, which has an unfortunate impact, when it comes to KeyboardEvent.key and onKeyDown in general.