Re: DOM Keyboard Event Level 3 questions about proposal

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),
nor the do they reflect which physical key was pressed (e.g. "A" changes
position between UK & French layouts).  It also doesn't help if the user
has e.g. Hebrew or Arabic keyboard layouts.

You could address some of the issues by conveying all the meanings the key
can possibly have, e.g. 2 on a US layout would give both "2" and "@", in
each key event, but that still won't work unless you do it across all the
user's installed keyboard layouts, which creates problems of its own (e.g.
if the user has both UK-en and FR-fr installed, which key is "2" on?).

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.

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.

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.

HTH,

Wez @ Google


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

> Егор Николаев <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
>
>