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 <[email protected]> wrote: > Any progress on the speccing of queryKeyCap? > > > On Fri, Feb 1, 2013 at 9:14 PM, Gary Kacmarcik (Кошмарчик) < > [email protected]> wrote: > >> On Fri, Feb 1, 2013 at 11:42 AM, Travis Leithead < >> [email protected]> 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 >> >> >
