[whatwg] oninput for contentEditable
Olli.Pettay at helsinki.fi
Wed Jun 24 03:21:41 PDT 2009
On 6/24/09 4:42 AM, Ojan Vafai wrote:
> Currently, textareas and text inputs support the "oninput" event
The event is "input" ;)
> 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
> We should also add a cancellable "onbeforeinput" event.
> USE CASE
> There are two main use cases.
> 1. A simple but comprehensive way to detect changes in a contentEditable
> region for features like autosave, transliteration, spelling correction,
> 2. Maintaining the data in a non-html model and using HTML as the view
> on the data. This requires capturing each change to the contentEditable
> element's contents and updating the model appropriately. Specifically,
> this is what Google Wave does.
> WORK AROUNDS
> Sites that use contentEditable currently rely on MutationEvents to
> detect when their contents have changed. MutationEvents are lower-level
> than the developer cares for, fire far too frequently for these
> use-cases, are complicated to use and have a significant performance impact.
> Sites that don't use MutationEvents use a long list of events (keydown,
> keyup, keypress, copy, paste, undo, etc.) to monitor changes. This is a
> lot of code and hard to get right. Not to mention that browsers don't
> actually have events for all the possible user-initiated actions.
> Google properties actually use the long list of events for semantic
> things (e.g. catch ctrl+z, cancel it and perform a custom undo) *and*
> listen to MutationEvents to catch cases where browsers don't fire an event.
> When a user-initiated action is going to modify the contents of a
> contentEditable element, a beforeinput event should be fired. The event
> should be cancellable and have an action property that is a string
> specifying what the user-action involved was (e.g. "paste",
> "inserttext", "undo", etc).
All the possible actions should be specified somewhere.
(and perhaps vendors could use vendor prefix if they add some
Why would you need "paste"? There is "paste" event
(though, not properly specified anywhere, I think);
And for "undo" and "redo" there is UndoManagerEvent
(terrible interface name, and 7.11.3 has a nice comment about
UndoManager :) ).
More information about the whatwg