This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Under current D3E draft, .key and .char are always same value if the event is caused by a printable key. And the example for Ctrl+'v' defines the 'v' key's .key and .char are 'v'. So, the result of .getModifierState('Control') is the only difference between 'v' key event with Ctrl and 'v' key event without Ctrl key. If web developers want to use text input editor with key events, they cannot know whether a key event would cause text input or not with .key or .char. So, I'd like to suggest that .key value should be same as current spec, but .char value should be empty string if the key event doesn't cause actual text input. I.e., 'v': { key: 'v', char: 'v' } 'v' with Shift: { key: 'V', char: 'V' } 'v' with Ctrl: { key: 'v', char: '' } 'v' with Ctrl and Shift: { key: 'V', char: '' }
I like that approach, since it is hard to know which combination does and which doesn't cause actual input. It all can be platform dependent.
I am posted the similar proposal to w3 mailing list http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0108.html In short, I proposed to "key" and "char" logical division. "char" property is an input character and it work as it describe in current draft. In the other hand, "key" property for any character keys with any special keys (Shift, Alt, Win/OS, Ctrl) is a US-en keyboard layout lowercased character representation similar to String.fromCharCode(key.keyCode).toLowerCase(). For non-character keys (http://www.w3.org/TR/DOM-Level-3-Events/#key-values-list) "key" property stay the same as in current drafg. In example: 'ы': { key: 's', char: 'ы' } 'ы' with Shift: { key: 's', char: 'Ы', shiftKey : true } 'ы' with Ctrl: { key: 's', char: '' , ctrlKey : true } 'ы' with Ctrl and Shift: { key: 's', char: '' , shiftKey : true, ctrlKey : true } As you can see the "char" property is useful only when it was a character input in some text field, in other cases we need cross-location case insensitive value to detect the current keyboard key pressed.
I posted some additional detail to the ML: http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0098.html
I don't understand the desire to bring the same value to "key" and "char" properties. And I don't understand the desire to make our (js-developers) work harder. What are good reasons to modify "key" value when one of modifier key pressed? We have crtlKey, shiftKey and altKey for that. We have "char" property for the original input symbol. So why I need to write extra code to detect to key I need, while I have good-old "keyCode" value. So instead use the new API, I will continue to use the old one.
(In reply to comment #4) > I don't understand the desire to bring the same value to "key" and "char" > properties. Anyway, if you still think so even you see D4E's .code, please file a new bug. This bug is opened only for the spec change request of .char value.
If we get rid of 'char' as proposed in bug 22071, then I don't believe this is an issue anymore. Masayuki, please verify and close if you agree. Or add details if you think this is still an issue that needs to be addressed. Thanks.
Absolutely. I'll close this bug after actually bug 22071 is fixed.
#22071 has been fixed in the latest ED.