[whatwg] oninput for contentEditable

[Ojan Vafai]

I've started a parallel discussion re: textInput on www-dom.
http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html

On Wed, Jun 16, 2010 at 5:13 PM, Ojan Vafai <ojan at chromium.org> wrote:

> 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/4fe12b41/attachment-0002.htm>