[whatwg] oninput for contentEditable

[Olli Pettay]

On 6/24/09 4:42 AM, Ojan Vafai wrote:
> SUMMARY
>
> Currently, textareas and text inputs support the "oninput" event
The event is "input" ;)

> 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.
>
> We should also add a cancellable "onbeforeinput" event.
"beforeinput" 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,
> etc.
> 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.
>
> PROPOSAL
>
> 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 
non-standard actions).

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 :) ).

-Olli