[D4E] KeyboardEvent.code and KeyboardEvent.queryKeyCap() are very strange spec

Hello.

I'm reading the spec of KeyboardEvent.code and 
KeyboardEvent.queryKeyCap(). Then, I'm feeling that the spec is very 
complicated and it doesn't make sense for non-US keyboard layout locales 
and for some keyboard layout users.

1. KeyboardEvent.code value is named from the unshifted character of 
en-US keyboard layout. However, this is not useful information for other 
locale developers. I think that the purpose of this value is, making 
identified value for each physical key. If so, it's not problem even if 
it's a just opaque number value. For example, it's easier to implement 
that UA sets scan code value on Windows, hardware_keycode value on GTK, 
native virtual keycode value on Mac.

2. KeyboardEvent.queryKeyCap() works with local identifier. However, it 
doesn't make sense. For example, we can say both locales of Standard US 
keyboard layout and Dvorak keyboard layout are "en-US". Similarly, some 
other locales have two or more keyboard layouts. So, using locale 
identifier for specifying keyboard layout is really wrong idea.

3. KeyboardEvent.queryKeyCap() takes any KeyboardEvent.code value. So, 
this method works like static class method of C++, not an instance's 
method. I think that this is overspec for web developers. I don't think 
such high level API is required. I think that the spec should remove 
KeyboardEvent.code attribute. And KeyboardEvent.queryKeyCap() works with 
the key of the cause of the event. Then, UA can store raw (system 
native) identifier of the key internally. This make implementations simpler.

4. Usually, key event handlers need to know (a) input character with 
current modifier state in current keyboard layout, (b) input character 
with different modifier state in current keyboard layout, (c) input 
character with current modifier state in current ASCII capable keyboard 
layout and (d) input character with different modifier state in current 
ASCII capable keyboard layout. For example, when a Russian keyboard 
layout user uses Russian keyboard layout with US standard keyboard 
layout. Then, Russian 'х' key has following meaning with Control key:

(a): ""
(b): "х" without Control key
(c): ""
(d): "[" without Control key

However, if another user uses it with Dvorak keyboard layout for ASCII 
character input, then,

(a): ""
(b): "х" without Control key
(c): ""
(d): "/" without Control key

Current draft thinks that returning "[" for "en-US" makes everybody 
happy. But I don't think so in this case.

5. I'd like to suggest KeyboardEvent.queryChar() instead of 
KeyboardEvent.code and KeyboardEvent.queryKeyCap(). 
KeyboardEvent.queryChar() has two arguments, one is modifier key state 
(space separated modifier key list, if there is unknown modifier key, it 
should raise an exception). The other is a bool value whether it 
specifies current keyboard layout or current ASCII capable keyboard 
layout. This method should work only with trusted key event because 
untrusted key event cannot have raw key information internally. If the 
user is using ASCII capable keyboard layout such as Japanese keyboard 
layout, then, the bool argument makes no difference for the result.

Then, If KeyboardEvent.char is same as (a) and KeyboardEvent.key is same 
as (b) without any modifier key, then, 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341 and 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18867 will be fixed simply.

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

Received on Thursday, 28 February 2013 03:10:34 UTC