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> wrote:

> > From: Wez <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