- From: Jacob Rossi <rossi@gatech.edu>
- Date: Tue, 25 May 2010 22:32:52 -0400
- To: Ojan Vafai <ojan@chromium.org>
- Cc: "Hallvord R. M. Steen" <hallvord@opera.com>, www-dom@w3.org, Erik Arvidsson <arv@chromium.org>, Alex Russell <slightlyoff@chromium.org>
On Tue, May 25, 2010 at 6:33 PM, Ojan Vafai <ojan@chromium.org> wrote: > On Tue, May 25, 2010 at 2:42 PM, Hallvord R. M. Steen <hallvord@opera.com> > wrote: >> >> On Tue, 25 May 2010 00:47:16 +0200, Jacob Rossi <rossi@gatech.edu> wrote: >> >>> .keyCode - Deprecated. Use .key >>> .charCode - Deprecated. Use .char >>> .key - Name of key being pressed. >>> .char - character value produced. Empty string if the key does not >>> produce a character (arrow keys, function keys, etc.). >> >> Short and sweet, with a clear link to the related properties from the >> past. Good naming, sir :) Thanks. > > Does .key have a value for character producing keys? If so, it is always > equal to the .char value? > It seems cleaner to me to keep the two totally separate and have .key be the > empty string for character producing keys. The fact keyCode and > charCode often have the same value and sometimes don't is a considerable > source of confusion for web developers. > Ojan In my opinion, .key would not be an empty string for character-producing keys. The spec gives a key name for every key (regardless of whether it produces a character) and this should be the value of .key. Keeping it this way allows for easy programming around 2 common scenarios: a. You care which key was pressed (.key) b. You care which character was produced (.char) If .key is an empty string for character-producing keys, then in scenario A you would have to consciously decide whether to use .key or .char based on whether the key produces a character or not. To simplify scenario A, I would prefer .key always have a value. A key is never abscent of a name. Rather, sometimes it just doesn't produce a character. --Jacob
Received on Wednesday, 26 May 2010 02:33:45 UTC