[whatwg] oninput for contentEditable

[Ojan Vafai]

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?

Ojan

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

> 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/20100827/331587cb/attachment-0002.htm>