Re: Event.key complaints?

On Thu, Nov 1, 2012 at 11:58 AM, Ojan Vafai <ojan@chromium.org> wrote:

> WebKit does not implement key/char, but does support keyIdentifier from an
> older version of the DOM 3 Events spec. It doesn't match the current key
> property in a number of ways (e.g. it has  unicode values like "U+0059"),
> but I do think it suffers from some of the same issues Hallvord mentioned.
>

On my US standard layout keyboard in Chrome, the key labeled [A] generates
events with a |keyIdentifier| of "U+0041" in both shifted and unshifted
state, and the key labeled [1!] generates events with a |keyIdentifier| of
"U+0031" in both shifted and unshifted states. It's identifying a
particular physical key on the keyboard rather than the current "meaning"
of the key - so in theory it's superior in  Hallvord's use case to |key|
which has multiple values for the same physical key. But as Ojan points out
the identification is done with Unicode code points that don't correspond
at all to the character that (may) be generated, which is going to confuse
developers further.

Keys without "printed representation" like "Enter", "Shift", "Up", etc. are
given those names for |keyIdentifier|, which is slightly more sensible.
Apart from exceptions like "Tab" and "Esc", which get the U+XXXX treatment.

On Thu, Nov 1, 2012 at 7:22 AM, Travis Leithead <
> travis.leithead@microsoft.com> wrote:
>
>> This is great feedback, which will need to be addressed one-way or
>> another before we finish DOM 3 Events.
>>
>> Are there any other implementations of key/char other than IE9 & 10? (And
>> Opera's Alpha-channel implementation). I did a quick check in the latest
>> Firefox/Chrome stable branches and couldn't detect it, but wanted to be
>> sure.
>>
>> > -----Original Message-----
>> > From: Hallvord R. M. Steen [mailto:hallvord@opera.com]
>> > Sent: Thursday, November 1, 2012 1:37 PM
>> > To: Ojan Vafai
>> > Cc: Travis Leithead; public-webapps@w3c.org
>> > Subject: 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
>>
>>
>