Re: DOM Level 3 KeyboardEvent

Jacob,

On 7 April 2011 17:55, Jacob Rossi <jrossi@microsoft.com> wrote:

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

OK.  That wasn't what I interpreted the description from the 2010 draft as
meaning.  Thanks for clarifying.

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

X11 KeySyms provide the vast majority of character & function meanings
in-use today, and have been extended (e.g. the XFree86 defines for "internet
/ media keys") to accomodate more without difficulty - they even have space
set aside for the whole of Unicode.  It's a pragmatic approach that avoids
the complexity of fully abstracting the meaning(s) a key (or other input
event) has / might have from the changes in its physical state.

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

That makes sense - my reading of that note implied the opposite, which is
why I wanted to query it.

  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".
>
>
Implementing this behaviour is non-trivial on Windows. The functions
provided by the platform for converting between VK codes and characters /
symbols have side-effects, for example in the presence of dead-keys.  Since
the "key vaue" depends on the keyboard state at the time of the "keyup",
these functions will need to be queried on WM_KEYUP to determine the correct
value, potentially affecting internal keyboard state for the calling thread,
and thereby affecting subsequent WM_KEYDOWN behaviour, including any
generated WM_CHAR.

Implementation difficulty aside, if the "key value" in "keyup" and "keydown"
cannot be made consistent, we could instead assign an opaque-Id to each
"keydown" (and preserve it across auto-repeat events). It's then possible
for applications to detect that a "keyup", or auto-repeat "keydown"
corresponds to an earlier event, and act accordingly.

Being able to determine that a "keyup" (or indeed an auto-repeat "keydown")
matches a preceding "keydown" is valuable.  For example, consider an
application which generates touch-tone sounds, for as long as the user
presses a key.  When the user presses "2" on their keyboard, they get the
appropriate tone while they hold it down.

For a US English layout, that will work so long as the user doesn't press
"Shift" after pressing "2" - if they do, then auto-repeat "keydown" events
become "@", and if they continue to hold down "Shift" then the "keyup" will
also contain "@", and the tone will continue until they next press and
release "2" without Shift.

For a French layout, to get "2" the user has to press "Shift"; otherwise the
key value will be e-acute.  In this case it's much more likely that the user
will end up releasing "Shift" before "2" and thereby end up with a
never-ending touch-tone drone.

Cheers,

Wez