W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Re: Keyboard events for accessible RIAs and Games

From: Кошмарчик <garykac@chromium.org>
Date: Sun, 24 Feb 2013 08:36:18 -0800
Message-ID: <CAGnkXoH5Yo_sieVx_KTp-DO_VpBRpiCcve7eZRY5-3O1jG37Ww@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Travis Leithead <travis.leithead@microsoft.com>, Hallvord Reiar Michaelsen Steen <hallvord@opera.com>, Webapps WG <public-webapps@w3.org>
I've updated the UIEvents document with an initial draft for

https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm (Section 4.1)

On Mon, Feb 18, 2013 at 8:09 AM, Gary Kacmarcik (Кошмарчик) <
garykac@chromium.org> wrote:

> I'll be updating the document this week. I'll send an update to the list
> after that happens.
> On Sat, Feb 16, 2013 at 7:40 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> Any progress on the speccing of queryKeyCap?
>> On Fri, Feb 1, 2013 at 9:14 PM, Gary Kacmarcik (Кошмарчик) <
>> garykac@chromium.org> wrote:
>>> On Fri, Feb 1, 2013 at 11:42 AM, Travis Leithead <
>>> travis.leithead@microsoft.com> wrote:
>>>>  I think we should give it another try by including it in our UI
>>>> Events spec. I like the idea of adding the static queryKeyCap(code) API to
>>>> Keyboard events. I wonder about the name though. A "key capability" doesn't
>>>> sound right. Are we querying for a key's locale name? e.g.,
>>>> queryKeyLocaleName(code)?
>>>  SGTM. I'll add a section to the spec for this.
>>> The KeyCap name refers to the "cap" placed over the keyswitch of the
>>> physical keyboard.  It's not a great name since there's no guarantee that
>>> the physical keyboard matches the current locale (although they usually
>>> do). However, the other (more accurate) names that I was able to come up
>>> with at the time were all rather unwieldy.
>>> Taking your name as a base, I think we'd need something like
>>> queryLocaleChar(locale, code) or queryLocaleKey since we'd be returning the
>>> equivalent of the 'char' (or 'key') attribute.
>>> Thinking briefly about this now:
>>> * If we return 'char' equivalents, we won't return dead keys or other
>>> virtual keys.
>>> * If we return 'key' values, then we need to address how to handle
>>> non-printable keys like "Shift" and "Home" that people might expect to be
>>> translated.
>>> * I think we'll also want the ability to specify modifier keys to apply
>>> to the 'code' (to generate shifted or AltGr'ed versions).
>>> I'll formalize this a bit more and send something out for comments.
>>> -Gary
Received on Sunday, 24 February 2013 16:36:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC