Note that the www-dom WG has objected to querying the localized,
accessible, user-friendly, keyboard symbol on grounds that it adds more
bits (or tiny fractions of bits) to the user identifyable information.
Contrieved usecases and advanced handwaving where employed. This is most
likely ending with A) not doing accessible, localized, user friendly things
or B) doing more user unfriendly things like popping "allow ..." dialogs
all over. I have forked issue B in its own thread, hopefully so that
neither A or B will be necessary.
On Thu, Jan 31, 2013 at 11:57 AM, Florian Bösch <pyalot@gmail.com> wrote:
> Sounds fine to me, any objections to add it to the Event Level 4 spec?
>
>
> On Thu, Jan 31, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen <
> hallvord@opera.com> wrote:
>
>> > What/where would be a good place to put the API for say
>> queryKeyCap(code) ?
>> Given that the implementation will have a KeyboardEvent property
>> specified on the global object (i.e. window) I'd propose
>>
>>
>> window.KeyboardEvent.queryKeyCap(code)
>>
>>
>> which returns a string with the symbol shown on the key.
>>
>>
>>
>> I.e.
>>
>>
>> On QWERTY:
>> KeyboardEvent.queryKeyCap('Digit2') === '2' // true
>>
>>
>> On AZERTY:
>>
>> KeyboardEvent.queryKeyCap('Digit2') === 'é' // true
>>
>>
>> etc.
>>
>> --
>> Hallvord R. M. Steen
>> Core tester, Opera Software
>>
>>
>>
>>
>>
>>
>
Received on Thursday, 31 January 2013 15:52:26 UTC