Re: DOM Keyboard Event Level 3 questions about proposal

Brad Pettit
There is a "location" property in keyboard event. When it has
"DOM_KEY_LOCATION_STANDARD" we can be sure, that entered value comes from
PC 101 Key US keyboard (according to the spec). All I suggest is precisely
this condition.
The main reason event.key != event.char is not to bring confusion in
developing, but not to break the js-developers best practice.
Consider this: I want (as front-end developer) to detect pressing "a" key.
Today I can check if event.keyCode == 65 when "a" key was pressed
regardless of actual user keyboard layout. In the new spec, there is no
such property as keyCode (deprecated) and I need to check "key" property,
that has the same value as "char" dependence of actual user keyboard
layout. So I actually have no "good" way to detect an "a" key pressed, and
the "bad" way is ignoring new spec and continue using "keyCode" property.
>Consider typing a percent character: the key that generates a "%" on a
typical US keyboard is not a % key. It is generated from a keydown on the
"5" key while the "shift" modifier key is also down. One could just as well
assign a function key to generate the keypress for '%' and it should still
be acknowledged as text input without the associated keydown/keyup. A given
character doesn't have to have corresponding key transitions.
In this case the new API should do the same as legacy "keyCode" property.
It works very well in most cases. Even if I mapped, for example, "z" key
to generate a "9", keyCode still will have the correct value. "key"
property should do exactly the same.


Masayuki Nakano
> I think that non-alphabet keys such as numeric keys and other keys (e.g.,
[, : and / keys) should respect the Shift key state. And also, Hebrew
keyboard layout, unshifted state inputs Hebrew characters but
> with shift key, inputs upper alphabet characters. So, I think that it
does make sense the behavior.
You not exactly understand me. Do we talking about the same? I suggest to
unified "key" property, so in any keyboard layout "key" property should
return exactly the same value, with shift key or without. It would be
helpful for game developers. What should I do if I want to create "["
shortcut (in any  keyboard layout )? The only way is to using legacy
keyCode property. For the "[" key event "key" should always be "[", but
"char" property should depend on keyboard layout and shift key.
And again, you have "char" property with actually entered value.

> If a printable key event doesn't cause text input
What the difference causing text input or not? WYSIWYG developers has
"char" property for detect entered character. Game and UI developers should
have "key" value to detect shortcuts(including in WYSIWYG editors). "char"
and "key" should not be the same. "key" value should be character values of
a normal QUERTY (en-US) layout
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19827 .

Masayuki Nakano do you see my demo http://h123.ru/-/tests/KeyboardEvent/ ?
That value you can't detect in Hebrew keyboard layout?



Again, the main reason why "key" should not be the same as "char" and "key"
should not modified by shift key is to bring to web-developers the same
mechanism as event.keyCode property.
Today key detection is
if(  event.keyCode  == 65 )
Tomorrow it should be
if(  event.key  == "a" )

I, as web-developer, do not understand why it should be
if( event.key.toLowerCase()  == "a" )  or worse if(  )

As for "code" property. It is the same problem as "key". Why this property
exists in the first place? What should "code" property bring to developer,
that keyCode can't? What should make me to abandon keyCode  in favor of
"code"?

And again,  https://www.w3.org/Bugs/Public/show_bug.cgi?id=19827 proposal
should work only if event.location ==  DOM_KEY_LOCATION_STANDARD.


On Tue, Feb 26, 2013 at 10:27 AM, Masayuki Nakano <masayuki@d-toybox.com>wrote:

> On 2013/02/26 14:14, Gary Kacmarcik (Кошмарчик) wrote:
>
>> On Mon, Feb 25, 2013 at 6:54 PM, Brad Pettit <Brad.Pettit@microsoft.com
>> <mailto:Brad.Pettit@microsoft.**com <Brad.Pettit@microsoft.com>>> wrote:
>>
>>
>>     As for the physical aspects of keys, there is also the human
>>     interface device aspect. See
>>     http://en.wikipedia.org/wiki/**USB_human_interface_device_**
>> class#USB_HID_API<http://en.wikipedia.org/wiki/USB_human_interface_device_class#USB_HID_API>
>>     and http://www.lvr.com/hidpage.htm
>>
>>     If an app cares about the keyboard at such a hardware level, perhaps
>>     a completely new set of events, or even a raw scan code state,
>>     should be exposed.
>>
>>
>> Have you taken a look at the UI Events (formerly DOM4 Events) spec:
>> https://dvcs.w3.org/hg/d4e/**raw-file/tip/source_respec.htm<https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm>
>>
>> We initially proposed using something like USB scancodes to the Keyboard
>> events, and that has evolved into the above spec.  For context, see
>> http://lists.w3.org/Archives/**Public/www-dom/2012JulSep/**0103.html<http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html>and
>> http://lists.w3.org/Archives/**Public/public-webapps/**
>> 2012OctDec/0623.html<http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0623.html>
>>
>> Looking forward to any comments you may have,
>> -Gary
>>
>>
> Although, I have some objection for .code of D4E. At for now, we should
> make the .key and .char behavior clearer and more useful for web
> application developers.
>
>
> --
> Masayuki Nakano <masayuki@d-toybox.com>
> Manager, Internationalization, Mozilla Japan.
>