DOM Keyboard Event Level 3 questions about proposal

On Mon, Oct 8, 2012 at 7:53 PM, Glenn Maynard
<glenn@zewt.org<https://mail.google.com/mail/?extsrc=mailto&url=mailto:glenn@zewt.org>
> wrote:
>
>
> I'd imagine you'd call a function to retrieve the button label in that
> position, so on QWERTY systems you'd say "press A" and on AZERTY you'd say
> "press Q".
>


On Mon, Oct 8, 2012 at 7:41 PM, Hallvord R. M. Steen
<hallvord@opera.com<https://mail.google.com/mail/?extsrc=mailto&url=mailto:hallvord@opera.com>
> wrote:

> Glenn Maynard <glenn@zewt.org<https://mail.google.com/mail/?extsrc=mailto&url=mailto:glenn@zewt.org>>
> skreiv Mon, 08 Oct 2012 17:06:35 +0200
>
>
>   Not supporting physical layout information makes that web app less
>> portable, not more, since it's building a keyboard layout dependency into
>> the app.
>>
>
> Well, it cuts both ways. If you as an author tell me as a user agent what
> to do when the user presses "H", I can do that for you on some touch screen
> or remote control. If you on the other hand tell me what to do when the
> user presses the key that is 7th from the left and 4th from the top I can't
> necessarily promise to translate that to a potentially very different
> device.
>
> Can we transform keyboardEvent.key to a more logical nature? So for any
device or keyboard layout if "key" value can be viewed as QWERTY en-US
lowercased symbol it should be viewed that way. Otherwise we always have
"char" property to determine the keyboard layout character. That enough for
most user case.