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 Thursday, 31 January 2013 08:46:42 UTC