- From: Ojan Vafai <ojan@chromium.org>
- Date: Wed, 24 Jun 2009 14:30:30 -0700
On Wed, Jun 24, 2009 at 11:51 AM, Olli Pettay <Olli.Pettay at 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.Pettay at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090624/8d7ce004/attachment.htm>
Received on Wednesday, 24 June 2009 14:30:30 UTC