Re: DOM Keyboard Event Level 3 questions about proposal

Егор Николаев <termi1uc1@gmail.com> skreiv Thu, 27 Sep 2012 19:47:20 +0200

>> 2) There's no clear statement about 'char' and 'key' values for special
>>> symbol key press events.

>> What Opera returns is the ASCII control character that key press would
>> insert in a terminal window or something.

> IE9 return empty value for 'key' and 'char' with Ctrl pressed, and null  
> for
> "char" and standard-compliance key value for 'key' with Alt pressed.

>> As a solution I'd like to suggest 'char' and 'key' logical division.
>>> 'Char' property should return input symbol (just like it does right  
>>> now)
>>> and 'key' property should always, for any special symbol key pressed,
>>> return lowercased US_en locale symbol for any symbol value.

I think this is the most author-friendly solution, it's also going to be  
the most backwards/cross-locale compatible one for future content given  
that a lot of it will still be written and tested on en-US keyboard  
layouts. We shouldn't state that it needs to be exactly the en-US keys  
though - otherwise, you web application won't work correctly when you ask  
a French azerty user to press A.

So can we alter the spec to say that "key" for alphanumerical and  
punctuation keys must be set to whatever key would be generated if no  
modifiers/dead keys/CapsLock/NumLock states were taken into account?

Of course, we still don't have a solution for the use case "I want to use  
keys that are in a specific location on the keyboard for my shortcuts"  
(disregarding configurations like azerty vs qwerty) - but that's more of a  
corner case and arguably one we should not accomodate because it makes the  
web app less portable?

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

Received on Monday, 8 October 2012 11:42:44 UTC