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

>>> (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 UTC