W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2010

examples of "event.key" usage broken?

From: Hallvord R. M. Steen <hallvord@opera.com>
Date: Wed, 03 Mar 2010 15:26:15 +0000
Message-ID: <20100303152615.nqj0im28gccwo840@staff.opera.com>
To: www-dom@w3.org
I'm still a bit confused regarding how the spec defines event.key values.

Looking at the definition of "character value"

it says that "character value" is

> a string representing a single Unicode character, such as a
> letter or symbol, as a UTF-16 character escape (e.g. '\u0041'
> for the Latin Capital Letter A key

The way I interpret this is that if you have an event listener containing


and press the key that generates an upper case "A" letter on your
keyboard, you would see an alert with the text '\u0041' in a
conforming implementation. Is this the intention?

If that's correct, the second example under


is entirely wrong. It says

event.key == "-" || // wrong, would be the string '\u002D' so  the
script would need to look like this:
//  event.key == '\\u002D'
// perhaps even like this:
// ( event.key == '\\u002D' || event.key == 'HyphenMinus'  )

   event.key.match("\p{Sc}") || // wrong, no implementation will match
a string containing the sequence backslash, u, 0, 0, 4, 1 to the
Unicode range of the "character value"

I think we should fix the spec rather than the example though - the
example code is probably the sort of user-friendliness we should aim

(If we really want to keep "unicode escape as a string"-values, would
you mind including an example of how a script should turn the string
'\u0041' into the character 'a'?)

(I personally think we should define event.key and event.character
where the former is a key name ("F5", "Backspace", "A") and the latter
the character in events that generate characters. This seems cleaner
than trying to mix up two different classes of keypresses with
different typical use cases into one single property. But that's just
my current opinion and I haven't thought a lot about it. It might
match current keyCode/charCode behaviour in Gecko in a more
user-friendly, high-level way though.. On the other hand, using lots
of string comparisons when you want to handle keyboard events doesn't
sound very efficient.)

Hallvord R. M. Steen
Core tester, Opera Software
Received on Wednesday, 3 March 2010 15:26:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:56 UTC