W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2012

DOM Keyboard Event Level 3 questions about proposal

From: (wrong string) Егор Николаев <termi1uc1@gmail.com>
Date: Mon, 8 Oct 2012 20:02:26 +0400
Message-ID: <CAP=KyTi2w0uEGYXw80YSEBcnR0JuuL20tX-=NzPDJRUkQSg9cA@mail.gmail.com>
To: www-dom@w3.org
Cc: Glenn Maynard <glenn@zewt.org>, "Hallvord R. M. Steen" <hallvord@opera.com>
On Mon, Oct 8, 2012 at 7:53 PM, Glenn Maynard
> 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
> 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.
Received on Monday, 8 October 2012 16:02:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:01 UTC