W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

Re: DOM Keyboard Event Level 3 questions about proposal

From: Florian Bösch <pyalot@gmail.com>
Date: Thu, 7 Mar 2013 21:44:58 +0100
Message-ID: <CAOK8ODjz+tzSfw6p54RbzBXRaMo-FiEnyno_kc8yXBdwM-=XLw@mail.gmail.com>
To: Егор Николаев <termi1uc1@gmail.com>
Cc: Masayuki Nakano <masayuki@d-toybox.com>, "www-dom@w3.org" <www-dom@w3.org>, Brad Pettit <Brad.Pettit@microsoft.com>
Oh and I forgot to mention that code is superseeding keyCode because
keyCode is a horrible, inconsistent mess where multiple keys issue the same
code, and the same keys can issue different codes. The code property isn't
doing that.


On Thu, Mar 7, 2013 at 9:43 PM, Florian Bösch <pyalot@gmail.com> wrote:

> On Thu, Mar 7, 2013 at 9:24 PM, Егор Николаев <termi1uc1@gmail.com> wrote:
>
>> As for "code" property. It is the same problem as "key". Why this
>> property exists in the first place? What should "code" property bring to
>> developer, that keyCode can't? What should make me to abandon keyCode  in
>> favor of "code"?
>>
>> And again,  https://www.w3.org/Bugs/Public/show_bug.cgi?id=19827proposal should work only if event.location ==  DOM_KEY_LOCATION_STANDARD.
>>
> The code property is belonging to the DOM Event Level 4 specification,
> which tries to address the issues of the DOM Event Level 3 specification
> that only offers char and key, both of which are of little use for shortcut
> systems and configurations thereof.
>
> Additional to the code property a queryKeyCap was introduced to facilitate
> being able to render a shortcut display according to the users keyboard
> layout (actually showing the key cap as present). event.code + queryKeyCap
> solve the issue that key and char do not.
>
Received on Thursday, 7 March 2013 20:45:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 March 2013 20:45:28 GMT