W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2010

Re: what should event.key be if a key inserts multiple characters?

From: Jacob Rossi <rossi@gatech.edu>
Date: Mon, 24 May 2010 18:47:16 -0400
Message-ID: <AANLkTinehT6djD49zAjjM7OfJUCBvYmG-NYa2BhVZ52D@mail.gmail.com>
To: www-dom@w3.org
Cc: ojan@chromium.org, hallvord@opera.com
>>> (FWIW, personally I think it would be nicer to have event.key and
>>> event.keyName rather than trying to conflate the two into one property.
>>> Don't remember if I already suggested that and it was rejected.)
>>
>> I agree that this would be easier for web developers to code to correctly.
>
>Thanks for confirming that there is some sense in what I was thinking :)

I agree that separating the key name and character value would be
easier. Unfortunately, I imagine many implementations may, at least
initially, continue support of keyCode and charCode for existing code
paths. This means that in practice the KeyboardEvent object would
have:
keyCode
charCode
key
keyName

which is a bit convoluted. But I suppose that's the unfortunate
consequence of the existing keyboard event model being broken.

Perhaps using  .key and .char might be a little less confusing names?

.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.).

where .key maps to the blue-background text and .char maps to the
green-background text in the Key Values Set [1].

> What should event.key be for cases like up, down, etc? I'd be OK with
> event.key being the empty string in those cases. That leaves the question of
> what keyName should be for text inserting key presses. It could be empty, or
> it could be equal to the event.key value. It's not clear to me which is
> better.

--Jacob

[1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#key-values
Received on Monday, 24 May 2010 22:48:11 GMT

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