examples of "event.key" usage broken?

Hi,
I'm still a bit confused regarding how the spec defines event.key values.

Looking at the definition of "character value"
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#glossary-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

alert(event.key);

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

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset-unicode

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

(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 13:42:33 UTC