Re: Re: Event.key complaints?

I wrote:


>> Hence, what I think would be most usable in the real world would be
>> making event.key a mapping back to un-shifted character values of a
>> normal QUERTY (en-US) layout. Authors are asking for stable reference
>> values for identifying keys, and that's the most stable and widely
>> known reference keyboard layout.


Gary responded:

> The main problem with using unmodified 'en-US' values is that it doesn't define values for keys
> that are not found on US keyboards. So, it's great for US keys, but completely ignores
> the rest of the world. 


Yep, and the solution to that is listing those keys and figuring out what their preferred key name should be. An implementation may still run into keys that have no identifier per the spec (so the spec says that "implementations that are unable to identify a key must use the key value 'Unidentified')" - but we should do a bit of work here to make sure as few keys as possible end up in this state.


Thanks for coming up with your list :-)


> Consider the following problems with using 'en-US':
> * What should the 'key' value be for the "B00" key (located next to the left shift - see
> the ISO/IEC9995-2 spec[1])? This is used in UK, Italian, Spanish, French, German and many other keyboards.


Several layouts place < here, some others &, \ or -. AFAIK the most common seems to be <, which also does not collide with any en-US unshifted key.


* What should the 'key' value be for "B11" key (next to the right shift)? This is used on Brazilian and Japanese keyboards.


Seems Brazilian layouts have / and Japanese \ here, however these already exist on US layout. I guess event.key could be '/\' (only half-serious here). Any other proposals?


> * And "C12" (tucked under Enter key when Enter takes 2 rows)? Keyboards with B00 usually have C12 as well.


Go with UK and make event.key # ?


> * And "E13" (between += and Backspace)? Found on Japanese (Yen key) and Russian keyboards.


With apologies to Russia, we might make event.key be ¥ for this one. (Seems some Russian layouts have \ here - but then, the "Russian" layout documened by Microsoft on http://msdn.microsoft.com/en-us/goglobal/bb964651.aspx had no less than two other keys for \).


> * For B00, the USB code = 0x64, name = "Non-US \ and |".
> * For B11, the USB code = 0x87, name = "International1".
> * For C12, the USB code = 0x32, name = "Non-US # and ~".
> * For E13, the USB code = 0x89, name = "International3".


I guess names like "International1" could be used if we struggle..
 
> As for the solution we need to come up with, it doesn't matter to me if it's:
> * encoded in the current 'key' field, or in a new field (although it'd be nice to have
> the 'key' field "do the right thing").


Sure, if we can agree on what that thing is :-)


> * a numeric value or a string (although I think a numeric value is preferable to avoid
> confusion with the 'char' value).


Hm.. Personally I think a numeric value would be too easily confused with the keyCode value (which authors are used to), and in many cases it would actually be the very same value. If we want to make .key a number it's tempting to suggest throwing out .key and standardising .keyCode properly instead. (Some legacy issues will make this somewhat less reliable as an "identify the key on the keyboard" solution, e.g. A's keycode moving around on the keyboard when switching from QUERTY to AZERTY).


> * the exact USB codes or something similar that we derive from them.


IMO it's nicer and more author-friendly to have some abstraction if we can make it easier to use..
 
>  But, we do need it to:
> * be able to uniquely identify each key on the keyboard.
> * be useful for all keys on all keyboards (and not just those that map nicely to 'en-US')
> * be straightforward to implement on all platforms.
 
I don't think we can fulfil all three - particularly not the latter. That's just the way it is :-( 

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

Received on Thursday, 8 November 2012 14:38:40 UTC