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

引用 Ojan Vafai <ojan@chromium.org>：

>> (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 :)

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

I agree on event.key being an empty string for up/down etc. My first  
though regarding keyName for text keys would be to match event.key (it  
makes semantic sense to refer to a key by a character name like  
"please press the A key") - though of course the implementation can  
not figure out what the actual label on the physical key is, so  
programming and reality does differ enough to make the empty string a  
better choice.

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

Received on Sunday, 23 May 2010 21:44:50 UTC