RE: DOM Level 3 KeyboardEvent

To be clear, character keys are expressed by providing a Unicode DOMString (not literally the characters "U+<code-point").

In your numpad example, 5 without NumLock is a function key. In Windows, we map VK_CLEAR to 'Clear' in IE9. But the spec recognizes that keyboard events are often platform specific. In your example on Linux, this would fall under that category of keys which the user agent should devise a value which is appropriate. Potentially, you could map this to 'Clear' for consistency with Windows. But devising your own value here would still be considered conforming in this case.

In general, creating an exhaustive map of cross-platform/cross-internationalization/cross-browser/cross-keyboard-layout/cross-keyboard-device key values has proven to be an insurmountable task. Many have attempted, all have failed. Thus we landed with character values (which are inherently cross-platform because we've chosen standardized Unicode) and then a set of known function keys. Additionally, building state machines off keyboard events is not reliable due to issues like focus changes where up events are lost.

As for Unicode surrogates, IE9 provides these as one string (rather than two events) as I indicated. This is for ECMAScript compatibility. Firing two events would be a lie in that two keys didn't actually go down. So the note you referred to is simply to point out that ECMAScript implementations will provide surrogate pairs in these cases. I can modify this a bit to clarify that this comes as one event.

-Jacob




From: wez@google.com [mailto:wez@google.com] On Behalf Of Wez
Sent: Thursday, April 07, 2011 7:28 AM
To: Jacob Rossi
Cc: schepers@w3.org; www-dom@w3.org
Subject: Re: DOM Level 3 KeyboardEvent

Jacob,

Thanks for taking the time to answer my questions.  My responses are inline, below.

On 7 April 2011 02:28, Jacob Rossi <jrossi@microsoft.com<mailto:jrossi@microsoft.com>> wrote:
> From: Wez <wez@chromium.org<mailto:wez@chromium.org>>
> What should a key
> produce if it has neither a character nor a function associated with it in a
> given context?
>
Correct, key takes into account modifiers and location. However, there are some circumstances where a key produces a character, but it's key value differs from the character produced. Examples include the spacebar (key: 'Spacebar', char: \u0020) or the add key (key: "Add", char: \u002B). See the Key Values Set for more info. [1]

When the key does not have an entry in the key values set, then you should provide the Unicode string of the character value produced (again, taking into account modifiers, etc.).

A set of values for function keys is provided in the key values set as well. For function keys which do not have an entry in this list, the UA may devise a value using the constraints defined in the key value algorithm. [2]

I think that matches my reading of the spec;

What you're saying is that keys are either "function" or "character" keys, and that "character" keys are expressed in the form "U+<code-point>", unless they appear in the Key Values set, in which case they are specified by name.  Function keys are always identified by a name, and if there isn't already a name in the Key Values set then there are constraints on how to define new ones.

I'm not aware of keys which are neither character or function keys. Can you provide an example? My assumption is that non-character producing keys are always function keys (not to be confused with F1-F10 only).

I'm thinking of keys which only have character values in the presence of certain combinations of modifiers and/or lock-states.

One example is the numeric-pad "5" key when NumLock is not set - Linux will produce XK_KP_Begin, which has no corresponding character, nor a name in the Key Values table.  (Windows will produce VK_CLEAR, which presumably maps to "Clear"?)

The more obvious examples are things like Ctrl+A or Alt+A, which don't necessarily produce any character output, nor correspond to a function in the Key Values Set.

> 2.  The "key" field is specified such that it can express keys with code
> points only from Unicode's Basic Multiligual Plane, which I gather is for
> ECMAScript conformance.  Is the intent to use UTF-16 surrogates for these,
> as is mention in the doc, in which case an application will see multiple
> KeyDown events for a single actual event, or could KeyDown and KeyUp support
> ECMAScript friendly key-identifier strings for BMP, and longer strings for
> characters outside that?
>

I believe the idea is to include UTF-16 surrogates pairs in a single event (the example cited in the spec is \uD84E\uDDC2). This should be ECMAScript friendly and avoid multiple events. But I'm not the best expert in this area. Perhaps Doug can comment here. I'll also check what we do in IE9.

There's a note regarding CharMod conformance in section 6.2.7 - is that the section you're referring to?  The note refers to escaping characters, and doesn't specify a particular implementation, rather it highlights some down-sides of the surrogate based approach.

> 3.  It seems that the only way for KeyUp to work is for the key-identifier
> it provides to match the one specified in the KeyDown that the key
> originally triggered, rather than reflecting whatever symbol the key would
> produce under the current modifiers - is that correct?  e.g. the squence
> Shift-down, a-down, Shift-up, a-up should give "U+0041" as the
> key-identifier for both a-down and a-up?  (BTW, the text for "keyup" seems
> to be a straight copy of that for "keyup" in the draft)
>

I believe the copy/paste error for keyup was fixed in one of my recent changes. Let me know if I missed something.

I posted this to the list before you made your changes; looking at the current editor's draft the wording looks to differ from that for "keydown" now.

No, keyup will not necessarily match keydown. This is critical because the state of modifiers can change in between these events (like in your example). Some applications care what the key value was at down, others at up--so it's important that the key value reflect the state when the key went down or up. I don't see why it would be a requirement that they match--in fact, it would be a farce to report "A" for the keyup in your example as that does not reflect the key value when the key came up.

In your example, the keydown would be "A" and the keyup would be "a".

In my experience applications look at key-down events to determine the effect of a key, and only use key-up to determine whether a key that was previously pressed has subsequently been released.  The specification you describe prevents this common use-case, unless each "key-down" event (and any auto-repeats) and the corresponding "key-up" include an Id unique to the key (e.g. a scancode, or a monotonically increasing key-down counter).

(Triggering actions (e.g. text entry) on key-up rather than key-down introduces latency and leads to unpredictable results; it's reasonably intuitive to press Shift before pressing the key marked "A", to get "A", but few users expect to have to release "A" before "Shift" in order to avoid getting "a".)

Thanks,

Wez