[whatwg] oninput for contentEditable

[Ojan Vafai]

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.

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.

Not sure exactly how to navigation this discussion as textInput is currently
in the DOM3 spec and input is in the HTML5 spec.

Ojan

On Tue, Mar 16, 2010 at 6:35 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>
>> So I have to ask... Why are events _before_ the edit needed?
>>
>> 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.
>>
>
> Here's a couple use-cases off the top of my head:
>
> Google Wave:
> 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.
>
> 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.
>
> 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.
>
> Typing at the beginning/end of links:
> 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.
>
> 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?
>
> 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?
>
> Ojan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100616/e8b92a1a/attachment-0002.htm>