- From: Егор Николаев <termi1uc1@gmail.com>
- Date: Fri, 8 Mar 2013 00:24:42 +0400
- To: Masayuki Nakano <masayuki@d-toybox.com>, "www-dom@w3.org" <www-dom@w3.org>, Brad Pettit <Brad.Pettit@microsoft.com>
- Message-ID: <CAP=KyThetM_Q0oQc+CaVLdjnC76oWm48i9WAq6adJ_pg3hk5JA@mail.gmail.com>
Brad Pettit There is a "location" property in keyboard event. When it has "DOM_KEY_LOCATION_STANDARD" we can be sure, that entered value comes from PC 101 Key US keyboard (according to the spec). All I suggest is precisely this condition. The main reason event.key != event.char is not to bring confusion in developing, but not to break the js-developers best practice. Consider this: I want (as front-end developer) to detect pressing "a" key. Today I can check if event.keyCode == 65 when "a" key was pressed regardless of actual user keyboard layout. In the new spec, there is no such property as keyCode (deprecated) and I need to check "key" property, that has the same value as "char" dependence of actual user keyboard layout. So I actually have no "good" way to detect an "a" key pressed, and the "bad" way is ignoring new spec and continue using "keyCode" property. >Consider typing a percent character: the key that generates a "%" on a typical US keyboard is not a % key. It is generated from a keydown on the "5" key while the "shift" modifier key is also down. One could just as well assign a function key to generate the keypress for '%' and it should still be acknowledged as text input without the associated keydown/keyup. A given character doesn't have to have corresponding key transitions. In this case the new API should do the same as legacy "keyCode" property. It works very well in most cases. Even if I mapped, for example, "z" key to generate a "9", keyCode still will have the correct value. "key" property should do exactly the same. Masayuki Nakano > I think that non-alphabet keys such as numeric keys and other keys (e.g., [, : and / keys) should respect the Shift key state. And also, Hebrew keyboard layout, unshifted state inputs Hebrew characters but > with shift key, inputs upper alphabet characters. So, I think that it does make sense the behavior. You not exactly understand me. Do we talking about the same? I suggest to unified "key" property, so in any keyboard layout "key" property should return exactly the same value, with shift key or without. It would be helpful for game developers. What should I do if I want to create "[" shortcut (in any keyboard layout )? The only way is to using legacy keyCode property. For the "[" key event "key" should always be "[", but "char" property should depend on keyboard layout and shift key. And again, you have "char" property with actually entered value. > If a printable key event doesn't cause text input What the difference causing text input or not? WYSIWYG developers has "char" property for detect entered character. Game and UI developers should have "key" value to detect shortcuts(including in WYSIWYG editors). "char" and "key" should not be the same. "key" value should be character values of a normal QUERTY (en-US) layout https://www.w3.org/Bugs/Public/show_bug.cgi?id=19827 . Masayuki Nakano do you see my demo http://h123.ru/-/tests/KeyboardEvent/ ? That value you can't detect in Hebrew keyboard layout? Again, the main reason why "key" should not be the same as "char" and "key" should not modified by shift key is to bring to web-developers the same mechanism as event.keyCode property. Today key detection is if( event.keyCode == 65 ) Tomorrow it should be if( event.key == "a" ) I, as web-developer, do not understand why it should be if( event.key.toLowerCase() == "a" ) or worse if( ) As for "code" property. It is the same problem as "key". Why this property exists in the first place? What should "code" property bring to developer, that keyCode can't? What should make me to abandon keyCode in favor of "code"? And again, https://www.w3.org/Bugs/Public/show_bug.cgi?id=19827 proposal should work only if event.location == DOM_KEY_LOCATION_STANDARD. On Tue, Feb 26, 2013 at 10:27 AM, Masayuki Nakano <masayuki@d-toybox.com>wrote: > On 2013/02/26 14:14, Gary Kacmarcik (Кошмарчик) wrote: > >> On Mon, Feb 25, 2013 at 6:54 PM, Brad Pettit <Brad.Pettit@microsoft.com >> <mailto:Brad.Pettit@microsoft.**com <Brad.Pettit@microsoft.com>>> wrote: >> >> >> As for the physical aspects of keys, there is also the human >> interface device aspect. See >> http://en.wikipedia.org/wiki/**USB_human_interface_device_** >> class#USB_HID_API<http://en.wikipedia.org/wiki/USB_human_interface_device_class#USB_HID_API> >> and http://www.lvr.com/hidpage.htm >> >> If an app cares about the keyboard at such a hardware level, perhaps >> a completely new set of events, or even a raw scan code state, >> should be exposed. >> >> >> Have you taken a look at the UI Events (formerly DOM4 Events) spec: >> https://dvcs.w3.org/hg/d4e/**raw-file/tip/source_respec.htm<https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm> >> >> We initially proposed using something like USB scancodes to the Keyboard >> events, and that has evolved into the above spec. For context, see >> http://lists.w3.org/Archives/**Public/www-dom/2012JulSep/**0103.html<http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html>and >> http://lists.w3.org/Archives/**Public/public-webapps/** >> 2012OctDec/0623.html<http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0623.html> >> >> Looking forward to any comments you may have, >> -Gary >> >> > Although, I have some objection for .code of D4E. At for now, we should > make the .key and .char behavior clearer and more useful for web > application developers. > > > -- > Masayuki Nakano <masayuki@d-toybox.com> > Manager, Internationalization, Mozilla Japan. >
Received on Thursday, 7 March 2013 20:25:10 UTC