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
