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
