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

RE: "keyIdentifier" Sucks

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>
Message-ID: <49142F02149340458FDD20841AD0AD5621D6E0A6@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
> 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 GMT

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