Bug 18867 - Web developers cannot know whether a key event will cause text input actually
Summary: Web developers cannot know whether a key event will cause text input actually
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Masayuki Nakano
QA Contact: public-webapps-bugzilla
Depends on: 22071
  Show dependency treegraph
Reported: 2012-09-13 06:11 UTC by Masayuki Nakano
Modified: 2013-08-17 22:20 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Masayuki Nakano 2012-09-13 06:11:56 UTC
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.


'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: ''  }
Comment 1 Olli Pettay 2012-09-13 07:54:16 UTC
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.
Comment 2 Egor Khalimonenko 2012-10-15 13:51:47 UTC
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.
Comment 3 Masayuki Nakano 2013-01-31 09:17:09 UTC
I posted some additional detail to the ML:
Comment 4 Egor Khalimonenko 2013-02-05 06:44:21 UTC
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.
Comment 5 Masayuki Nakano 2013-03-12 02:42:45 UTC
(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.
Comment 6 Gary Kacmarcik 2013-05-18 01:19:43 UTC
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.
Comment 7 Masayuki Nakano 2013-05-18 01:29:55 UTC
Absolutely. I'll close this bug after actually bug 22071 is fixed.
Comment 8 Gary Kacmarcik 2013-08-17 22:20:15 UTC
#22071 has been fixed in the latest ED.