RE: DOM Keyboard Event Level 3 questions about proposal

I gather this is further confusing the intent of key events and text input events. Consider the intent of the separate events. 

(This comment is from the perspective of one who has implemented key events in a browser on multiple platforms.)

A Key down/up event corresponds to a key transition. The transition is generally associated with hardware, thus it also has a key layout aspect. In order to get the side-effects from the operating system utilities, language customization, hardware vendors, etc, it is commonly done by the driver and OS. The text generated by a key varies between keyboards. The keypress event is normally generated when the OS determines a text character should be generated from some given key transitions. Applications that want text should deal with keypresses, and apps like games that care about hardware should look for keydown/keyup. Oftentimes, the UA doesn't even know what type of device is sending the event, just that it is being sent. Thus an IR remote control might appear exactly the same as a keyboard, which may appear exactly the same as soft keyboard running on a smart phone.

Regarding the example below: there is no key for a lower-case "c." A lower-case C character is generated when the physical key corresponding to "C" is pressed and no modifier keys are pressed. One might as well name it the "0x43" key since it is simply a name that has an associated code. In fact, the system could be configured with a utility to generate some other character when the physical C key is pressed.

Maybe the separation of "key names" from "text characters" should be made more explicit. Without the UA implementing a keyboard driver and interfering with the system behavior, there isn’t much it can do to prevent a given character from being generated based on some key transitions while still conforming to the conventions of the OS.

Regarding KeyboardEvent.char being set to the input character: at the point a physical key down or key up is received, there is no definitive "character" to associate, nor is there a definitive way to modify the character that will be generated by the UA.

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.

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.

Trying to blend semantics of key events and text input events has long been a source of confusion, and it is going to cause even more confusion if the line that differentiates them is blurred further.

Brad Pettit
Microsoft Corporation

-----Original Message-----
From: Masayuki Nakano [mailto:masayuki@d-toybox.com] 
Sent: Thursday, January 31, 2013 12:46 AM
To: Егор Николаев; www-dom@w3.org
Subject: Re: DOM Keyboard Event Level 3 questions about proposal

Hi,

I had filed following bugs before stating this thread:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18867


For i18n and combination with modifier keys, I believe that current .key and .char value definition in the latest draft isn't useful for web applications.

First, it doesn't make sense .key and .char always have same value for printable keys.

Even though pressed key is a printable key, the key may not input any characters. For example, Ctrl + C doesn't cause input any characters into text editor. But according to the example in the draft, the 'C' key event should have { key: "c", char: "c" }.

I think that KeyboardEvent.char should always indicate the input character with its modifier state. So, I think that the C key event should have following values:

C                  { key: "c", char: "c" }
C + Shift          { key: "C", char: "C" }
C + Ctrl           { key: "c", char: "" }
C + Shift + Ctrl   { key: "C", char: "" }

So, I agree with that char value shouldn't be a control character like less than 0x20. Such control code isn't useful for web applications.

And by this approach, web applications can distinguish the key event will cause text input or not so.

Similarly, if =/+ key on US-ASCII (QWERTY) keyboard layout:

=/+                 { key: "=", char: "=" }
=/+ + Shift         { key: "+", char: "+" }
=/+ + Ctrl          { key: "=", char: "" }
=/+ + Shift + Ctrl  { key: "+", char: "" }

I think that key should be unmodified character except Shift key. Then, web application can access both unshifted and shifted characters with the key events. If Shift key is also ignored for deciding key value, the Ctrl + + can be never handled by web applications. In my idea, web applications can handle it with ignoring the Shift key state.

For non-ASCII capable keyboard layout, e.g., д/Д key on Russian keyboard layout (the key is positioned at L key in US keyboard layout),

д/Д                 { key: "д", char: "д" }
д/Д + Shift         { key: "Д", char: "Д" }
д/Д + Ctrl          { key: "д", char: "" }
д/Д + Shift + Ctrl  { key: "Д", char: "" }

Or:

д/Д                 { key: "l", char: "д" }
д/Д + Shift         { key: "L", char: "Д" }
д/Д + Ctrl          { key: "l", char: "" }
д/Д + Shift + Ctrl  { key: "L", char: "" }

Probably, the latter example is preferred by web application developers. 
However, This may be impossible in some cases. For example, if the user is using software keyboard on mobile phone, the software keyboard layout may not be like QWERTY, e.g., could be like NumPad.

And the resolving cost could be expensive. So, basically, I think browsers shouldn't resolve the keys to another layout's keys. However, indeed, the resolved value is useful if Ctrl key (or Command key on Mac) is pressed. So, following result might be the best:

д/Д                 { key: "д", char: "д" }
д/Д + Shift         { key: "Д", char: "Д" }
д/Д + Ctrl          { key: "l", char: "" }
д/Д + Shift + Ctrl  { key: "L", char: "" }

When the char value is empty, i.e., user doesn't try to input a character with printable key, resolving the key value to ASCII capable keyboard layout might be better.

However, there is a concern even with this idea. If the resolved character is not [0-9a-zA-Z], the character might be able to input from the non-ASCII capable keyboard layout directly. Then, two keys may indicate same key value unexpectedly.

So, if we take this idea, it should be limited that the resolved value should be allowed only if the resoled character is [0-9a-zA-Z].

But if there is shortcut key registration system which I mentioned in:
http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0097.html

, the resolving isn't necessary. I.e., the first example is enough for web application developers.

Additionally, there is AltGr case. For example, AltGr + 7// inputs { on German keyboard layout. Then:

7//                  { key: "7", char: "7" }
7// + Shift          { key: "/", char: "/" }
7// + AltGr          { key: "7", char: "{" }
7// + Shift + AltGr  { key: "/", char: "" }

I.e., key value should be unmodified value, i.e., without AltGr.

Finally, if there is some platforms which cannot resolve the unmodified input character, they should set same value as char.

I'd like to know other people's idea for my idea.

Thank you.

--
Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.

Received on Tuesday, 26 February 2013 02:56:55 UTC