[whatwg] oninput for contentEditable
Ojan Vafai
ojan at chromium.org
Wed Jun 24 14:30:30 PDT 2009
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-0002.htm>
More information about the whatwg
mailing list