[whatwg] oninput for contentEditable

SUMMARY
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.

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,
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).
After the DOM has been modified, fire the input event, which also has the
action property.

The action property is needed for the use-case of maintaining a non-html
model of the content.  For example, when the HTML representation of the
content has complicated HTML content (e.g. an image with a caption) that
maps to one atomic unit in the data model, the web app needs to catch events
like backspace, cancel the event and update the DOM and it's model
appropriately.

You can currently do most of this using the long list of events exposed. But
there's no guarantee that all user-initiated events will be exposed via an
event and, even if they were all exposed, it's a lot of complex code to make
it work.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090623/c7a25716/attachment.htm>

Received on Tuesday, 23 June 2009 18:42:18 UTC