W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2009

[whatwg] oninput for contentEditable

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 24 Jun 2009 14:30:30 -0700
Message-ID: <78dc8440906241430p4c8388d5n955f74c7768cad7b@mail.gmail.com>
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

-------------- 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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:13 UTC