Re: Event.key complaints?

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