- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 22 Sep 2009 18:38:09 -0700
- To: Travis Leithead <travil@microsoft.com>
- Cc: Doug Schepers <schepers@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
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 UTC