Re: DOM Keyboard Event Level 3 questions about proposal

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? :-)

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.

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

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.

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

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

> 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 :-]

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Friday, 26 October 2012 08:05:36 UTC