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

Hi, thank you for your reply and sorry for the delay.

On 2013/02/28 17:15, Hallvord Reiar Michaelsen Steen wrote:
>> 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 believe that the information that *is* useful for those developers is already available in the other properties, no? If .code is meant for developers who want to write cross-locale applications and only need to take physical key positioning into account, it makes sense to me to use a standard en-US layout as a reference simply because it's a well known keyboard layout that most developers either will be familiar with already or easily find descriptions of.

My concern is, the code values don't indicate that they are named for 
en-US (QWERTY) keyboard layout. Therefore, I believe that a lot of web 
developers will misunderstand the meaning of code value.

For example, when Japanese web developers try to handle Ctrl+':', they 
might (want to) compare with 'Colon' rather than 'Quote'. It feels very 
strange for me. Indeed, as you say, .key value should be ':'. However, 
at least in Japan, it's not intuitive behavior because most Japanese 
people don't familiar with en-US keyboard layout (especially, which 
punctuation key inputs which character). So, I don't feel en-US QWERTY 
layout is well known layout for the people all over the world.

>> 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.
>
>
> True, but this is probably harder for authors to understand.

Yeah, I realized that if we use unique numbers like keyCode, most web 
developers will probably compare the code value with fixed number. Then, 
such developer's web application won't work for unexpected keyboard 
layout. In Japan, most people don't familiar with en-US keyboard layout, 
however, actually, few people prefer en-US keyboard layout rather than 
JIS keyboard layout. So, it's possible to cause such inaccessible web 
application. However, I don't like the value name is based on en-US 
QWERTY layout... Hmm...

>> 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.
>
>
>
> ..but would those values always match cross-platform for a given key? We certainly *don't* want to make JS authors write platform-specific code..

Yeah, I agree with that. My main idea is, the .code value should not be 
referred by web developers directly. In the current draft, they should 
always use queryKeyCap().

Therefore, one of my suggestion is, .code property should be removed 
because in my understanding, the code value is useful only for an 
argument of queryKeyCap().

>> 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.
>
>
>
> This is a good point, we may need to specify names like 'en-us-standard' or 'en-us-dvorak'.

Yeah, but it will probably be named by each implementation. I mean that 
same keyboard layout might be named different names.

And like Microsoft Keyboard Layout Creator (MSKLC, 
http://msdn.microsoft.com/en-us/goglobal/bb964665.aspx), there can be 
unknown (not well known) keyboard layouts. So, my conclusion is, it's 
impossible to give names to keyboard layout.

And also, I believe that all web developers need only following keyboard 
layout's information.

a. Current (active) keyboard layout.
b. Current ASCII capable keyboard layout.
c. QWERTY keyboard layout of en-US.

For usual web applications, (a) and (b) are enough. And also, (c) might 
be necessary if web developers want to know the physical key position on 
a PC keyboard. E.g., game developers?

>> 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.
>
>
> The use case for this was displaying information to the user, for example telling the user what keys should be pressed for various actions. Hence it is necessary to be able to call this method even outside of event handlers, and it's spec'ed as a "static class method" for that reason.

Hmm, I understand. However, I feel that such API shouldn't be in 
KeyboardEvent because it doesn't make sense web developers need to 
create KeyboardEvent instance for getting the information... Perhaps, 
shouldn't DOM window or document have it?

>> 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.
>
> Doesn't help the above use case, unfortunately.

Yeah, I understand the use case. However, I'm still thinking that .code 
value doesn't necessary for KeyboardEvent.

In my understanding, there are two *different* needs:

A. Needs an API for letting developers know the input character of the 
fired keyboard event with other modifier state or layout.
B. Needs an API for letting developers know the input character of 
specified keyboard event.

So, aren't these API better and enough for developers?

const unsigned long DOM_KEYBOARD_LAYOUT_CURRENT               = 0x00;
const unsigned long DOM_KEYBOARD_LAYOUT_CURRENT_ASCII_CAPABLE = 0x01;
const unsigned long DOM_KEYBOARD_LAYOUT_QERTY_EN_US           = 0x02;

KeyboardEvent.getInputChar(
   unsigned long keyboardLayout, // one of DOM_KEYBOARD_LAYOUT_*
   DOMString modifierState // space separated modifier state
);

this returns the input character with the specified condition.

Something.getKeyCap(
   DOMString code // same as code value defined in current draft
   unsigned long keyboardLayout // one of DOM_KEYBOARD_LAYOUT_*
);

this returns the key caption of the specified key.

Then, the code *attribute* doesn't necessary. Only the code values are 
necessary. Then, we can avoid the issue that web developers will compare 
.code value directly.

>> 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.
>
>
>
> I personally agree that it would be nicer to fix KeyboardEvent.char and KeyboardEvent.key than adding yet-another-property with KeyboardEvent.code. I guess IE10 implemented .char and .key as spec'ed already though - we could probably ignore the Opera Presto implementation as it's being discontinued and few developers targeted their content at Opera, but if IE already shipped something it's a lot harder to re-architect it :-(

I think that IE can change the behavior. The .key and .char have only 
been implemented on IE. So, such state attribute isn't useful for most 
web developers. And also, even if the change will cause something 
trouble on a few web applications, such developers should change the 
code for the latest spec. D3E is still "Working Draft".

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

Received on Monday, 11 March 2013 03:33:41 UTC