RE: DOM Keyboard Event Level 3 questions about proposal

A few comments:

1. clarification: although it appears to be attributed to me, I did not make the comment about the location property.

2. the significance of a “keydown” or “keyup” event is that there is no text character associated with a keydown or keyup. That association depends on the context of the event. Keypress events have text, Keydown/KeyUp events do not. They are associated with the input device and MAY result in generation of one or more keypress events. Keypress events can exist independently of keydown/keyup events, and not all keydown/keyup events will result in keypress events (think function keys). When you enter text, the text comes from keypress events. Trying to assign a character to a keydown or keyup in the event model is a design error because the driver or OS determines what text character is sent for a physical key event. When you press the key that has an ‘A’ printed on it, there is no “A” text character to associate, and it is unknown whether an “A” “a” or even some other character will be generated. Consider it to have been a convenient implementation detail that the “keycode” when you press the A key is the same as the A character code. Example: In windows, when the key with both 5 and % is pressed, the window will receive a keydown message with the code corresponding to the 5 key. One of the side effects of a keydown event for the OS (not the app) for the 5 key is to post a keypress event for the % character if the shift key was down, or a 5 if the shift key was not down. This mapping is generally not performed by the user-agent or the application, but by the OS. Another point to consider is a device such as an infrared remote control. The remote control repeatedly sends the same code as long as the button is pressed. Inferring a keydown or keyup event for a given press of a button is open to interpretation by the driver. At an even lower level are the device-specific scan codes, with those being even more closely associated with the keyboard state.

3. I am not clear why there is a need for a web application to translate physical device input to text, thus it’s not clear why there should be a “character” in a keydown event. There are some keys that do not have mapping to text input, and some that may. The keyboard location property –may- be useful in regards to keydown/keyup events for certain scenarios, but it would be inaccurate to either attribute a keypress event to a specific physical key or include a character code in a keydown/keyup.

--Brad Pettit

From: wez@google.com [mailto:wez@google.com] On Behalf Of Wez
Sent: Thursday, March 07, 2013 1:47 PM
To: Егор Николаев
Cc: Masayuki Nakano; www-dom@w3.org; Brad Pettit
Subject: Re: DOM Keyboard Event Level 3 questions about proposal


On 7 March 2013 12:24, Егор Николаев <termi1uc1@gmail.com<mailto:termi1uc1@gmail.com>> wrote:
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.

DOM_KEY_LOCATION_STANDARD does not necessarily mean that the key came from a PC 101 Key US keyboard.  The mention of a 101-key keyboard in the spec is just an example.

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"?

The UI Events "code" identifies the physical key. It does not depend on the configured input language & layout nor on modifier state.
The DOM 3 "key" identifies the meaning of the key in the current context, so it takes into account the input language & layout, and modifier state.
The "keyCode" has no actual definition, though in IE and WebKit-based browsers it gives the VK code for the event. VK codes aren't affected by modifiers, but do move according to the keyboard layout, so they neither identify the physical key, nor its meaning in the current context.

For example, say your game wants to use the US-layout WASD keys as movement keys. On a French keyboard those keys are labelled ZQSD. The four keys have the same "code" values regardless of the language, but if you use "keyCode" you'll have to check for a different set of codes depending on the language.


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<mailto: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>
<mailto:Brad.Pettit@microsoft.com<mailto: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

    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


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 and
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<mailto:masayuki@d-toybox.com>>
Manager, Internationalization, Mozilla Japan.