Define constants for legacy KeyCode use by TV4Fun · Pull Request #2222 · emscripten-core/emscripten (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation5 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
The HTML5 spec for KeyboardEvents is still a draft, any many browsers
(Chrome and Firefox included) still have yet to implement support for it.
Unfortunately, this means that to use keyboard input in these browsers,
we still have to rely on legacy keyCode support. This implements the keyCode
definitions provided at
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Virtual_key_codes,
which will work in Chrome and Firefox, and probably other browsers as well.
The HTML5 spec for KeyboardEvents is still a draft, any many browsers (Chrome and Firefox included) still have yet to implement support for it. Unfortunately, this means that to use keyboard input in these browsers, we still have to rely on legacy keyCode support. This implements the keyCode definitions provided at https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent#Virtual_key_codes, which will work in Chrome and Firefox, and probably other browsers as well.
I feel a bit uncertain about merging this in, since it's deprecated functionality and will not work consistently across browsers. I think it would be better as a wiki page or a gist, which we could perhaps point to in the html5.h documentation, saying "if you really want to do this, then here's stuff you can copy-paste." How does that sound?
That seems reasonable enough. However, I would also recommend adding some extra notes to the headers saying that the spec is still a draft and many members of that KeyboardEvent struct do also not work consistently across browsers.
juj added a commit that referenced this pull request
…the current implementation and deprecation status of the various fields. See also pr #2222.
Ok, I updated the documentation. If this proves to become a big pain for several developers, I guess we should research up the status in different browsers in close detail and offer a best practices wiki page, or a very light abstraction layer to unify everything, or something similar. @TV4Fun, let me know if the wording I now added did not feel like it hit the spot.
That seems like a good compromise to me. The note seems reasonable.