W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

Re: [DOM3Events] keydown/keyup asymmetry for held keys (key repeating)

From: Wez <wez@chromium.org>
Date: Fri, 8 Jul 2011 11:12:31 -0700
Message-ID: <CALekkJcxJGZY-dfLWe8kG8PcgMd24+ioYZz=AeCYwxJ4yEw-1Q@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-dom@w3.org
On 22 June 2011 11:25, L. David Baron <dbaron@dbaron.org> wrote:

> http://www.w3.org/TR/DOM-Level-3-Events/#events-keyboardevents says:
>  # Holding down a key must result in the repeating the events
>  # keydown, keypress (when supported by the user agent), and
>  # textinput (when the keypress results in text input) in this
>  # order, at a rate determined by the system configuration.
>
> I think this is a bad idea because it introduces asymmetry between
> the keydown and keyup events (which I think authors would reasonably
> expect to be symmetric) and because it defines keydown in a way that
> also violates a reasonable expectation -- that it be fired when the
> key is pressed (just like the existing "mousedown" event).
>

Applications can't rely on symmetry between keydown and keyup events even if
they are generated in pairs, as you suggest, with no auto-repeat keydown
events.  The key value is specified as reflecting the meaning of the key in
the context of the current modifiers, which means applications cannot rely
on the value being consistent between keydown and keyup events for the same
physical key.

Of course, combining keydown key-repeats with the key value specification
also means that an application can't distinguish a keydown repeats from new
keys being pressed if the modifier state changes.

Basically applications can't use keydown and keyup events to track key state
as the spec currently stands, without referring to the deprecated keyCode
field.

Wez @ Google
Received on Friday, 8 July 2011 18:15:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT