[whatwg] oninput for contentEditable

[Ojan Vafai]

WebKit would like to implement this in the (very) near future. Before
proceeding, we'd like to hear from other browser vendors that you're roughly
on board with this direction of adding beforeinput and input events.

Here are the changes I can think of that would result from this:
1) Fire "input" event for contentEditable areas as well as for text-entry
form controls.
2) For every case where we'd fire "input", add a new "beforeinput" event
that fires before the DOM has been modified.
3) Add a new InputEvent interface with an "action" attribute to use for
"input" and "beforeinput" events.
4) For events with an "inserttext" action attribute, also provide a "data"
attribute that specifies the text being inserted. For other actions, "data"
is the empty string.
5) "input" events may be batched as long as they have the same action. In
the case of "inserttext" actions, the data attribute is the accumulation of
text being inserted. One strange side effect here is that there may be
multiple "beforeinput" events per "input" event fire, although it's not
unlike having multiple keydown events before a single keyup.

The list of actions still needs to be enumerated, but some obvious ones are
inserttext, undo, redo, copy, paste, cut and drop.

I also think we should get rid of the textInput event in deference to this
more useful event, but that's a discussion we can have on www-dom once this
is resolved. As far as I know, only WebKit currently implements textInput.

Ojan

On Tue, Jul 14, 2009 at 6:02 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 23 Jun 2009, Ojan Vafai wrote:
> >
> > Currently, textareas and text inputs support the "oninput" event that
> > fires on all user-initiated modifications to their content. We should
> > add this event to contentEditable elements as well and add an "action"
> > property the specifies what action the user took that caused the input
> > event.
>
> I haven't yet added this.
>
> I think we should probably address the various problems with
> contenteditable all at once, to make sure the solution is coherent
> overall. I'm watching what happens with the mutation event changes and
> tracking proposals for various other changes to contentEditable.
>
> It may be that we need to defer these changes to after HTML5 reaches last
> call, though, and have them in a future version next year some time.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100303/5e2c7ab2/attachment-0002.htm>