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

On Tue, May 18, 2010 at 1:02 PM, Hallvord R. M. Steen <hallvord@opera.com>wrote:

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

On Thu, May 20, 2010 at 4:30 PM, Jacob Rossi <rossi@gatech.edu> wrote:

> 3. The key is intended to produce the text string "Up" but not as a
> macro of multiple keys. This is the hardest situation to handle. As
> you pointed out, it can cause confusion with the actual Up arrow key
> (in this example). Currently, the spec prefers character values over
> key names. My suggestion would be to modify the spec's preference for
> character values (only in the scenario that the character value
> collides with the key name of another  key which has no character
> value; e.g. Up, Down, etc. ) and instead give the key name for the
> configurable key. Then, the textInput event is used to capture the
> generated string:
>
>   1. keydown 'KeyName' (KeyName decided by implementation)
>   2. textInput 'Up'
>   3. keyup 'KeyName'
>

I think you did a good job capturing the cases we need to worry about.

I feel like we if do this, then the third case will just be poorly supported
by web pages. This is a distinction that few web developers will know to
code for. So, in practice you'll end up with developers using event.key as
if this sort of text input didn't exist (i.e. always treating
event.key=="Up" as the up arrow key).

Ojan