Re: DOM Keyboard Event Level 3 questions about proposal

Hi.

I wonder, why we need modified (upper cased) key value if we already have
shiftKey=true.

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

It will make JS-developing harder with no reason.
Instead doing so:

switch(event.key) {
  "a":
  "b"..
}

I will have to write  switch(event.key.toLowerCase()) . What point of it?

And I don't understand the idea of bringing the same value to key and char
properties. What point of it either? With the different values of key and
char properties it will bring more freedom to analyze keyboard input data.

I created a demo of my original proposal
h123.ru/-/tests/KeyboardEvent/(issue here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19827)
As you can see on this demo, different values of key and char is more
useful and provides more opportunities for developing.

About different input methods: We already have six "location" property
values: KEY_LOCATION_STANDARD, KEY_LOCATION_LEFT, KEY_LOCATION_RIGHT,
KEY_LOCATION_NUMPAD, KEY_LOCATION_MOBILE, KEY_LOCATION_JOYSTICK. It's solve
the problem with mobile/TV/other input methods incompatible with standard
PC-keyboard. If "location" ==  KEY_LOCATION_MOBILE or
KEY_LOCATION_JOYSTICK, "key" value should not obey to the same rules as for
over "location" values.

And one more note. Shortcut binding it not only Ctrl+<key> binding, it's
also Shift+<key> != <char>, and also one-key binding, such as in
first-person shooter game. In my game i want to detect WASD regardless of
current use keyboard layout (I am talking about PC keyboard or virtual
keyboard on Laptop, not about TV remote, or something incompatible with
standard PC-keyboard). And in my  first-person shooter, Shift key also have
shortcut unrelated with WASD.

In short:
key "w" ->  go ahead
key "s" ->  go forward
if(event.shiftKey){ speed /= 2 }




On Thu, Jan 31, 2013 at 12:46 PM, Masayuki Nakano <masayuki@d-toybox.com>wrote:

> 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=18341>
> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=18867<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<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.
>