18867 2012-09-13 06:11:56 +0000 Web developers cannot know whether a key event will cause text input actually 2013-08-17 22:20:15 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified All All RESOLVED FIXED P2 normal --- 22071 1 masayuki masayuki bugs garykac mike mounir termi1uc1 www-dom public-webapps-bugzilla oldest_to_newest 73743 0 masayuki 2012-09-13 06:11:56 +0000 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: '' } 73750 1 bugs 2012-09-13 07:54:16 +0000 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. 76304 2 termi1uc1 2012-10-15 13:51:47 +0000 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. 82393 3 masayuki 2013-01-31 09:17:09 +0000 I posted some additional detail to the ML: http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0098.html 82570 4 termi1uc1 2013-02-05 06:44:21 +0000 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. 84285 5 masayuki 2013-03-12 02:42:45 +0000 (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. 87861 6 garykac 2013-05-18 01:19:43 +0000 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. 87866 7 masayuki 2013-05-18 01:29:55 +0000 Absolutely. I'll close this bug after actually bug 22071 is fixed. 92227 8 garykac 2013-08-17 22:20:15 +0000 #22071 has been fixed in the latest ED.