- From: Travis Leithead <travil@microsoft.com>
- Date: Tue, 22 Sep 2009 14:48:19 +0000
- To: Doug Schepers <schepers@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
> From: Travis Leithead > > 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?) Scratch that last one--just noticed DocumentEvent::convertKeyIdentifier... -Travis
Received on Tuesday, 22 September 2009 14:49:01 UTC