[
https://issues.apache.org/jira/browse/TAP5-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194797#comment-14194797
]
Felix Scheffer commented on TAP5-2400:
--------------------------------------
That's a good question. Keyboard events are a mess.
There is *"char"* which was removed from the DOM Level 3 Events. It's supported
by IE9 and Firefox 33. Chrome and Opera do not support it. Not sure about
Safari.
There is *"charCode"* which is not (no longer?) part of the DOM Level 3 Events
but it's seems to be supported by all major browsers.
There is *"code"* in the latest draft of the DOM Level 3 Events but I dont
think there's a single browser that actually supports it (Firefox 33 and
Chrome/Chromium 37 do not)
There is *"key"* which is part of the DOM Level 3 Events and supported by IE9
and Firefox 29. Chrome, Safari and Opera do not support it at the moment.
There is *"keyCode"* which is not part of the DOM Level 3 Events. It is
supported by all major browsers but it can behave strangely depending on the
browser and the actual event.
Personally I tend to use "keyCode" or jQuery's "which" but using "key" and a
polyfill for older browsers would be better.
I would definitely use "charCode" instead of "char".
> EventWrapper's "key" and "char" properties are broken
> ------------------------------------------------------
>
> Key: TAP5-2400
> URL: https://issues.apache.org/jira/browse/TAP5-2400
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.4
> Reporter: Felix Scheffer
>
> The EventWrapper copies the properties "key" and "char" from the native
> event but KeyboardEvent has neither a "key" nor a "char" property in Chromium.
> According to https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent
> "char" is only supported by the IE and "has been dropped from DOM Level 3
> Events".
> According to
> https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.key neither
> Chrome nor Opera nor Webkit supports the "key" property at the moment
> I think "char" should be removed from the EventWrapper and there should be a
> fallback solution using "keyCode" when the browser does not support "key"
> There is a proposal for a "code" property but it's still a working draft:
> https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.code
> I checked with Prototype and jQuery but there are no real differences. jQuery
> wraps the native event with jQuery.Event but the actual values for these
> properties are the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
