<div class="gmail_quote">On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky <span dir="ltr"><<a href="mailto:bzbarsky@mit.edu">bzbarsky@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">So I have to ask... Why are events _before_ the edit needed?</div>
<br>
If we add these, then you have to define what happens when those event handlers modify the state of the DOM in arbitrary ways, including carrying out operations that spin the event loop, operations that make the edit that's about to happen nonsensical, and so forth. It's a huge chunk of spec and implementation complexity. So I'd like to see some very compelling use cases to even consider it.<font color="#888888"><br>
</font></blockquote><div></div></div><div><br></div><div>Here's a couple use-cases off the top of my head:</div><div><br></div>Google Wave:<br><div>They keep a model of the content separate from the html contents of the contentEditable region. In order to make that work, for every user-action, they need to either mimic what the browser did or cancel the default browser behavior and perform that action themselves. In both cases, having a beforeinput event makes the code much more sane, less brittle and often more performant.</div>
<div><br></div><div>In the case where they want to cancel the default browser behavior (e.g. undo/redo), they get the beforeinput event, cancel it and then do their thing. Without beforeinput, they need to wait for the action to happen and then either make sense of the changes to the DOM, or undo the changes and reapply their own changes. Those both lead to brittle and, in some cases, expensive code.</div>
<div><br></div><div>In the case where they want to let the browser perform it's default action, having the beforeinput event allows them to properly bookend a user-action and know with confidence that they've correctly handled it. Instead, they currently have very complex and brittle logic listening to every event under the sun in order to make sure they catch every possible user-action.</div>
<div><br></div><div>Typing at the beginning/end of links:</div><div>Another more general use-case is needing to modify the DOM before the user-action occurs. This comes up often when typing at the beginning/end of a link (or otherwise special inline element). Different apps want different behavior (e.g. should the text inserted go inside the link or after it). Currently, controlling that behavior is really difficult. You need to capture every time the selection changes and mess with the DOM/selection appropriately to get the text inserted in the right place. In theory, you *could* do this with just the input event, but that would get you back into reverse engineering whatever the user-action was, which is again brittle and difficult to get right.</div>
<div><br></div><div>Is that a bit more convincing with respect to the need for a beforeinput event? beforeinput aside, are you in support of extending the input event to contentEditable elements and adding the data/action attributes?</div>
<div><br></div><div>Any thoughts from Opera developers? Anne, your previous comments on this thread make it sound like you support this and would consider adding it to Opera?</div><div><br></div><div>Ojan</div>