<div class="gmail_quote"><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">SUMMARY</span><div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br>
</span></font></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">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.</span></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">We should also add a cancellable "onbeforeinput" event.<br>
<br>USE CASE</span></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">There are two main use cases.</span></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">1. A simple but comprehensive way to detect changes in a contentEditable region for features like autosave, transliteration, spelling correction, etc.</span></div>
<div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">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.<br>
<br>WORK AROUNDS<br><br></span></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">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.</span></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">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.</span></font></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">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.</span></font></div>
<div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><br>PROPOSAL<br><br></span></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">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). </span></font></div>
<div><span style="font-family:arial, sans-serif;border-collapse:collapse">After the DOM has been modified, fire the input event, which also has the action property.</span></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br>
</span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">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.</span></font></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">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.</span></font></div>
<div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div>Ojan</div>