- From: Кошмарчик <garykac@chromium.org>
- Date: Sun, 24 Feb 2013 08:36:18 -0800
- 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>
- Message-ID: <CAGnkXoH5Yo_sieVx_KTp-DO_VpBRpiCcve7eZRY5-3O1jG37Ww@mail.gmail.com>
I've updated the UIEvents document with an initial draft for queryKeyCap/queryLocale 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