W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: "keyIdentifier" Sucks

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 22 Sep 2009 18:38:09 -0700
Cc: Doug Schepers <schepers@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
Message-id: <898AD0A8-5D29-4F2A-AA27-C06C14B9988D@apple.com>
To: Travis Leithead <travil@microsoft.com>

On Sep 22, 2009, at 7:43 AM, Travis Leithead wrote:

>> From: www-dom-request@w3.org [mailto:www-dom-request@w3.org] On  
>> Behalf Of Doug Schepers
>>
>> Sean Hogan wrote (on 9/22/09 12:13 AM):
>>>
>>> Doug Schepers wrote:
>>>>
>>>> Here are some counter-proposals, in roughly descending order of my
>>>> preference:
>>>> 1) keyname (I'd need to come up with some other term for what I'm
>>>> calling a "key name" in the spec, but that's fine)
>>>> 2) keystring
>>>> 3) keyvalue
>>>> 4) keyaddress
>>>> 5) keyid (I don't like this one for a number of reasons)
>>>> 6) keypeek (joke)
>>>>
>>> The XBL spec uses "key" for event filtering. Seems okay to me.
>>
>> Too general.  When you're describing the feature, you need a more  
>> specific
>> hook.  Just saying "key" doesn't distinguish it from a physical key,
>> keyCode/charCode, a VK, or even a scancode.
>
> A few more choices to consider...
>
> keyresult
> keychar
> keyinput
> keytext
> charvalue
> [*]Unicode (to provide easy access to the Unicode string?)

These should all use mixedCase to be consistent with DOM naming style.  
Personally, I think "key" is the best name out of these. The attribute  
tells you what key was pressed. Code like this:

if (evt.key == "Q") {
     // ...
} else if (evt.key == "Enter") {
    // ...
}

seems very natural to me.

Regards,
MAciej
Received on Wednesday, 23 September 2009 01:38:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT