Re: Event.key complaints?

Travis wrote:

>>  Hallvord, sorry I missed your IRC comment in today's meeting, related to
>> DOM3 Events:****
>> ** **
>>     <hallvord_> event.key is still a problem child, authors trying****
>>     to use it have been complaining both to me and on the mailing****
>>     list****
>> ** **
>> Could you point me to the relevant discussions?

To which Ojan Vafai replied:

> I'm not sure what specific issues Hallvord has run into, but WebKit
> implementing this property is blocked on us having a bit more confidence
> that the key/char properties won't be changing.

Probably wise of you to hold off a little bit ;-), and thanks for  
pointing to relevant discussion threads (I pasted your links at the  
end).

Opera has done the "canary" implementation of the key and char  
properties, according to the current spec. As such, we've received  
feedback from JS authors trying to code for the new implementation,  
both from internal employees and externals. According to this  
feedback, although the new spec attempts to be more i18n-friendly it  
is actually a step backwards compared to the event.keyCode model:

If, for example, you would like to do something when the user presses  
[Ctrl]-[1], under the old keyCode model you could write this in a  
keydown handler:

if(event.ctrlKey && event.keyCode == 49)

while if you want to use the new implementation you will have to do  
something like

if(event.ctrlKey && ( event.key == 1 || event.key == '&' || event.key  
== '1' ))

and possibly even more variations, depending on what locales you want  
to support. (That's three checks for English ASCII, French AZERTY and  
Japanese hiragana "wide character form" layouts respectively - I don't  
know of other locales that assign other character values to this key  
but they might exist). Obviously, this makes it orders of magniture  
harder to write cross-locale applications and places a large burden of  
complexity on JS authors.

In the current spec, event.key and event.char are actually aliases of  
each other for most keys on the keyboard! If the key you press doesn't  
have a "key name" string, event.key and event.char are spec'ed as  
being the same value [1].

This "aliasing" doesn't really add up to a clear concept. If two  
properties have the same value almost always, why do we add *two* new  
properties in the first place?

This is also the underlying cause for other reported problems with the  
new model, like the inability to match [Shift]-[A] keydown/up events  
because event.key might be a in keydown but A in keyup or vice versa.

I would like the "story" of event.char and event.key to be that  
event.char describes the generated character (if any) in its  
shifted/unshifted/modified/localized glory while event.key describes  
the key (perhaps on a best-effort basis, but in a way that is at least  
as stable and usable as event.keyCode).

Hence, what I think would be most usable in the real world would be  
making event.key a mapping back to un-shifted character values of a  
normal QUERTY (en-US) layout. Authors are asking for stable reference  
values for identifying keys, and that's the most stable and widely  
known reference keyboard layout.

Alternatively, we can spec that event.key describes the un-shifted,  
un-modified key state from the current keyboard layout AND standardise  
event.keyCode they way it's already implemented rather than  
deprecating it, because it covers some use cases better than what our  
new stuff does. But my preference would be going the event.key =  
QUERTY (en-US) route, and I plan to report a bug or two on making that  
happen.
-Hallvord

[1] Spec describes event.key as follows: "If the value is has a  
printed representation, it must match the value of the  
KeyboardEvent.char attribute"
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-KeyboardEvent-key

http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0010.html
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0713.html
http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0103.html
http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0030.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341

Received on Thursday, 1 November 2012 12:37:19 UTC