On Wed, Jun 24, 2009 at 11:51 AM, Olli Pettay <olli.pet...@helsinki.fi>wrote:
> On 6/24/09 6:49 PM, Anne van Kesteren wrote: > >> On Wed, 24 Jun 2009 12:21:41 +0200, Olli Pettay >> <olli.pet...@helsinki.fi> wrote: >> >>> Why would you need "paste"? There is "paste" event >>> (though, not properly specified anywhere, I think); >>> >> >> I'd think you want an event that covers all editing actions. Also, >> that's what the input event does for <input>. >> >> By the way, did anyone ever implement textInput from DOM Level 3 Events? >> If not maybe someone should email www-dom about "nuking" that. > > >> Why would you want to nuke textInput? Perhaps textInput (in some extended > form) could be used for contentEditable and we could deprecate > input event. textInput has the advantage that it has .data textInput only fires when you input text. It does not fire when you delete, paste, bold (i.e. ctrl+b), etc. That does make me wonder whether certain input events should have a data property (i.e. action=inserttext). It's a little ugly to just have data in some cases, but it's no more ugly than rich text libraries needing to listen to input+textInput or input+keydown. On the other hand, maybe it we should try to spec data for all input event cases. Ojan