W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

Re: DOM Keyboard Event Level 3 questions about proposal

From: Wez <wez@chromium.org>
Date: Mon, 11 Mar 2013 08:32:36 -0700
Message-ID: <CALekkJeTVJkYvek_A5pdNkvRf3PLgP-kGETsJOrNrLOPD6mJ5g@mail.gmail.com>
To: Егор Николаев <termi1uc1@gmail.com>
Cc: Florian Bösch <pyalot@gmail.com>, "www-dom@w3.org" <www-dom@w3.org>
On 11 March 2013 07:58, Егор Николаев <termi1uc1@gmail.com> wrote:

>
>  But why the "code" values is so complicated?
>>> For example: event.code='ShiftLeft'. If I need to detect the exactly
>>> 'Shift' key, I can read 'location' property.
>>>
>>
The reason for the "LeftShift"/"RightShift" naming is that the "code" value
uniquely identifies a physical key, rather than the *meaning* of the key,
which may not be unique.  If you just want to trap Shift, you should listen
for events with "key" equal to "Shift", for example.


> The location property designates things such as numpad, function row,
>> center keys, I don't think shift left and right would have a different
>> location (I could be wrong though).
>>
>
>
>>  In the most common scenarios I need to detect just 'Shift' key without
>>> exactly location.
>>>
>> Yeah, but you wouldn't want to throw away the possibility of identifying
>> left or right. Therefore it's not the same.
>>
>
> "DOM_KEY_LOCATION_LEFT
> The key activated originated from the left key location (there is more
> than one possible location for this key).
> Example: the left 'Control' key on a PC 101 Key US keyboard.
> ...
> DOM_KEY_LOCATION_RIGHT
> The key activation originated from the right key location (there is more
> than one possible location for this key).
> Example: the right 'Shift' key on a PC 101 Key US keyboard." (from spec).
>
> You can check "location" values in IE9+ or in Opera 12+ for "Shift" keys.
> So for left "Shift" location would be DOM_KEY_LOCATION_LEFT, for right
> "Shift" -  DOM_KEY_LOCATION_RIGHT.
>
>
>>
>>> Another example is event.code="Digit2". While I can understand
>>> "ShiftLeft" value - it brings additional information, I can't understand
>>> the "Digit"/"Key" prefix. There is no other "2" value in the spec, no need
>>> to do the "code" values so complicated. Why can't it be just "2" as well as
>>> "KeyA" be just "A"?
>>>
>> Because they're not "2" or "A", they might be  "ش" or "١" or "た". The
>> name is choosen to designate that you're not dealing with alphanumerics
>> here, but with key identifiers.
>>
> I don't see much differences between "KeyA" and "A" except of complication
> of js-code writing. When the js-developer using "code" property he should
> know that it's mean and that values it can contains. "Key"/"Digit" prefix
> is useless and redundant, and requires to write more code. In "code"
> property the "A" value can serve as unique key as well as "KeyA" value.
>

The "code" field names are based on the US English layout, for consistency
with the USB specification's descriptions of keys. The values have forms
such as "KeyA" and "Digit1" to make clear that they don't necessarily
*mean*"A" and "1" in the context of the current language layout or
modifiers.

e.g. The event with code="KeyQ" will have key="a" under  a FR-fr layout, or
key="A" under FR-fr with a shift key pressed.
Received on Monday, 11 March 2013 15:34:12 GMT

This archive was generated by hypermail 2.3.1 : Monday, 11 March 2013 15:34:14 GMT