WebKit has added the input event to contentEditable nodes. That part of this proposal seemed non-controversial. Do other browser vendors support changing the description of this event to apply to contentEditable nodes as well?<div>
<br></div><div>Ojan<br><br><div class="gmail_quote">On Wed, Jun 16, 2010 at 5:33 PM, Ojan Vafai <span dir="ltr"><<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I've started a parallel discussion re: textInput on www-dom. <a href="http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html" target="_blank">http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html</a><div>
<div></div><div class="h5"><br><br><div class="gmail_quote">
On Wed, Jun 16, 2010 at 5:13 PM, Ojan Vafai <span dir="ltr"><<a href="mailto:ojan@chromium.org" target="_blank">ojan@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We've given this a bit more thought and come the the conclusion that textInput basically does what we want out of beforeInput, except that it doesn't currently fire for actions like undo/redo. So, basically, we're proposing that textInput should fire for any DOM modifying event and, ideally, that it would be renamed beforeInput.<div>
<br></div><div>The one exception is for IME input. beforeInput/textInput wouldn't fire for each composition update due to technical limitations of the Mac platform. There's a thread about this on www-dom already.</div>
<div><br></div><div>Not sure exactly how to navigation this discussion as textInput is currently in the DOM3 spec and input is in the HTML5 spec.</div><div><br></div><div><font color="#888888">Ojan</font><div><div></div>
<div><br><br><div class="gmail_quote">On Tue, Mar 16, 2010 at 6:35 PM, Ojan Vafai <span dir="ltr"><<a href="mailto:ojan@chromium.org" target="_blank">ojan@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote">On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky <span dir="ltr"><<a href="mailto:bzbarsky@mit.edu" target="_blank">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>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><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><font color="#888888"><div>
Ojan</div>
</font></blockquote></div><br></div></div></div>
</blockquote></div><br>
</div></div></blockquote></div><br></div>