[whatwg] oninput for contentEditable
Olli Pettay
Olli.Pettay at helsinki.fi
Thu Mar 4 01:57:18 PST 2010
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. `._.-(,_..'--(,_..'`-.;.'
>
>
More information about the whatwg
mailing list