Re: DOM Keyboard Event Level 3 questions about proposal

On 7 March 2013 12:24, Егор Николаев <termi1uc1@gmail.com> wrote:

> 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.
>

DOM_KEY_LOCATION_STANDARD does not necessarily mean that the key came from
a PC 101 Key US keyboard.  The mention of a 101-key keyboard in the spec is
just an example.


> 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"?
>

The UI Events "code" identifies the physical key. It does not depend on the
configured input language & layout nor on modifier state.
The DOM 3 "key" identifies the meaning of the key in the current context,
so it takes into account the input language & layout, and modifier state.
The "keyCode" has no actual definition, though in IE and WebKit-based
browsers it gives the VK code for the event. VK codes aren't affected by
modifiers, but do move according to the keyboard layout, so they neither
identify the physical key, nor its meaning in the current context.

For example, say your game wants to use the US-layout WASD keys as movement
keys. On a French keyboard those keys are labelled ZQSD. The four keys have
the same "code" values regardless of the language, but if you use "keyCode"
you'll have to check for a different set of codes depending on the language..


> 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.
>>
>
>