- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Wed, 03 Mar 2010 13:37:58 +0000
- To: www-dom@w3c.org
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