RE: Event.key complaints?

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

Received on Thursday, 1 November 2012 14:23:20 UTC