- From: Philippe Le Hegaret <plh@w3.org>
- Date: Tue, 15 Mar 2005 17:59:45 -0500
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-dom@w3.org
- Message-Id: <1110927585.12154.29.camel@localhost>
On Thu, 2005-03-03 at 14:14 -0500, L. David Baron wrote: > On Monday 2005-01-24 14:04 -0500, Philippe Le Hegaret wrote: > > In the case of a key repeat, you should generate multiple > > keydown/textInput/keyup, and not just the textInput. That's exactly what > > the repeat functionality is about. It does have the drawback of not > > having the ability to differentiate between fast key input from a user > > on a keyboard and the key repeat functionality. > > That drawback seems significant (especially for things like online > games, where holding down something that's normally a repeating key > could cause a state transition), and the fix for it seems reasonably > simple. I propose modifying the model by: > > 1) adding back keypress events (They would carry the same data about > the key that keyup and keydown events carry now.), and > > 2) making keyup and keydown events fire only when a key goes up or > down. I agree that this is a drawback, but we need to guarantee that the keyboard events will act the same way in multiple platforms. I would be interested in the feasibility of the implementation of your approach. From rom what I remember when doing some tests a few years ago, keypress events varied a lot depending on the platform. I can certainly try those tests again if you believe this is no longer the case. btw, if reintroduced, the keypress would need to be generated after a keyup, but before a textInput. Philippe
Received on Tuesday, 15 March 2005 22:59:52 UTC