Re: DOM Keyboard Event Level 3 questions about proposal

On 26 October 2012 01:04, Hallvord R. M. Steen <hallvord@opera.com> wrote:

> Wez <wez@chromium.org> skreiv Fri, 26 Oct 2012 01:01:28 +0200
>
>
>  The unmodified-keys proposal is more or less what WebKit's keyIdentifier
>> currently implements, based on an pre-2011 draft of the DOM Level 3 Events
>> spec; it suffers from the same issues as Windows' virtual key codes -
>> codes
>> neither reflect the meaning of the key in the current context (e.g. the
>> key with "2" printed on it gives e-acute on a French layout without
>> modifiers),
>>
>
> ..but if event.char covers this use case, why is it a problem that
> event.key doesn't? :-)
>

I'm not sure what use-case you have in mind; your proposal was to add a
field that gives the key value that the key would have in the absence of
any modifiers, for the current layout.  I'm pointing out that for the "2"
key that will result in e-acute rather than "2", which isn't helpful to
content that wants the user to press the key that has "2" printed somewhere
on it. :)

It doesn't really seem to be an issue for the key [2] in French btw, I
> still get the event.keyCode=50 in keydown/up when testing a French keyboard
> setup in IE on XP.


event.keyCode does not have a standardized meaning.

In IE (and browsers that chose to match IE's implementation, e.g. WebKit)
it simply reflects the Windows Virtual Keycode for the key, which is VK_2
for that key regardless of shift state and layout.  If you repeat the same
test with the key marked "A" on a US English keyboard you'll find that that
generates VK_A under en_US but VK_Q under fr_FR.

 nor the do they reflect which physical key was pressed (e.g. "A" changes
>> position between UK & French layouts).
>>
>
> Yes, some issues created by the way the underlying platform handles the
> keys. Does anyone know how users in France currently deal with such issues
> - for example, if they want to play a game where [A] is used for a
> shortcut, would French users typically switch to an English layout to play
> that game more conveniently?
>
>
>  It also doesn't help if the user has e.g. Hebrew or Arabic keyboard
>> layouts.
>>
>
> As far as I can tell, this statement is incorrect. I just added Arabic and
> Hebrew layouts to my Windows setup and tested in IE. The virtual keycode
> (event.keyCode in IE's keydown/keyup) remains 65 for [A] in Hebrew and
> Arabic, also tested Russian Cyrillic. It seems the underlying logic is that
> if the key is mapped to something *outside* US-ASCII, the virtual keycode
> is not re-mapped. If it's changed to something inside US-ASCII (as in A and
> Z switching place for AZERTY), the keycode is remapped. The same logic
> seems to apply to punctuation character keys (the [,] key switches keycode
> for French, where it generates a ; character).
>

See above; keyCode is a non-standardized field that simply reflects what
the Windows Virtual Keycode for the key would be.

Again, with your proposal of adding a field that reports the key value that
the key would generate in the absence of modifiers, that field would
clearly contain a Hebrew character if the layout is Hebrew, in the same way
that the key value would be Hebrew.

The so-called OEM keys (the ones that are not A-Z and typically handle
> various local characters, @, umlauts etc) are however vigorously re-mapped
> in all sorts of confusing ways. I believe it's generally not possible to
> detect from a keycode which OEM key is pressed.


If you mean event.keyCode then yes; more than that, it's not standardized
across browsers nor platforms.  If you use a WebKit-based browser like
Chrome on a Linux system with a Hebrew layout, for example, then I don't
think the keyCode field will be populated properly at all.

 On another thread we've proposed a secondary key code scheme that assigns
>> layout and modifier independent codes; combining something like that with
>> APIs to let content query for the key "values" that a particular code
>> would
>> generate under some combination of layout & modifiers would address the
>> concerns expressed on this thread.
>>
>
> This sounds very, very complicated - as far as I can tell the problem is
> in fact much smaller than it might first appear, mostly limited to keyboard
> layouts that re-arrange US-ASCII characters to a different layout than the
> default en-US one, such as French AZERTY and presumably Dvorak. So, either
> we spec a "map non-en-US keyboard layouts that move US-ASCII-keys around
> back to the en-US values for event.key" or we leave it up to JS authors to
> use event.locale and figure out that the user needs a [Q] shortcut instead
> of an [A].


Mapping values back to the en-US values means that content will end up
displaying en-US characters in their UI, resulting in a bad experience for
users, and you also have to decide how to cope with keys that don't exist
on one or other layout.

Similarly, requiring JS authors to examine locale and code layout-specific
mappings and choose suitable keys for each is a bad experience for authors.

If I understand Erop's example correctly, he'd prefer to handle a fixed key
code across all languages, and present the layout-specific symbol when
displaying the shortcut to the user, rather than have to cope with
locale-specific keycodes.

 e.g. an app can opt to use Ctrl+A as a shortcut if a language with a
>> Latin-alphabet is installed, and fall back to Ctrl+<x> where <x> is the
>> symbol printed on the key that would be "A" on an en_US layout, for
>> example, and still be able to display the right thing to the user.
>>
>
> This sounds like yet another use case to me: "get the symbol associated
> with the key to display a non-confusing message / guide to end users".


That's intrinsically part of the use-case Erop's describing, I think.

 e.g. a game can express the up/down/left/right keys in terms of these
>> secondary codes (assuming a standard PC-style keyboard), but display the
>> symbols corresponding to those keys under the current layout to the user.
>>
>
> I sure hope no layout re-maps those :-]


I meant the game's up/down/left/right keys, which lots of apps choose to
use WASD for, which of course do then get re-mapped between layouts. :)