[whatwg] oninput for contentEditable

[Ojan Vafai]

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/20100316/eed6fb0a/attachment-0001.htm>