[whatwg] oninput for contentEditable

[Olli Pettay]

On 3/4/10 4:11 AM, Ojan Vafai wrote:
> 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.

textInput should be pretty useful when combined with the new key events 
and with the all the properties DOM 3 Events draft defines for it.
Webkit's textInput isn't quite that, IIRC.



-Olli

>
> Ojan
>
> On Tue, Jul 14, 2009 at 6:02 PM, Ian Hickson <ian at hixie.ch
> <mailto: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.   `._.-(,_..'--(,_..'`-.;.'
>
>