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