Re: examples of "event.key" usage broken?

Hi, Hallvord-

I am still in the process of clarifying the character value aspect of 
key events in the spec; there is a lot of cruft left over from earlier 
drafts, where things were rather different.  In your example, the value 
of event.key would be "A", not "\u0041".

A major revision of the spec, based on feedback such as yours and that 
of the i18n folks, is on its way... probably in early April, since I 
have some other non-DOM3 Events duties I will be concentrating on in March.

I look forward to your review then.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Hallvord R. M. Steen wrote (on 3/3/10 10:26 AM):
> 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.)
>

Received on Wednesday, 3 March 2010 20:47:59 UTC