[webkit-dev] beforeinput and input events for contenteditable/designMode

[Ojan Vafai]

This discussion stalled on whatwg a bit. Sending an update in the hopes that
we can start getting code reviewed and checked in here.

In the discussion on whatwg, there weren't any vendors that opposed adding
beforeInput/input, but there also wasn't outright support. There was
hesitance from Boris Zbarsky about whether the complexity of a beforeInput
event was worth it. I tried to get more feedback from other vendors, but I
think this is all we're going to get. So, we'd like to move forward where it
makes sense.

The obvious case is firing the input event for contentEditable areas as well
as text controls. There's a patch up at
https://bugs.webkit.org/show_bug.cgi?id=26526 for this that I intend to
start reviewing shortly.

As for the beforeInput event, upon further inspection, the textInput event,
which we currently support, already meets most of what we're looking from
for beforeInput. So, instead of adding another event in addition to
textInput, we're instead proposing that textInput be extended to fire for
all the cases we fire input. I've started a discussing this on www-dom:
http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html.

So, I'd like to see the following steps taken in this order:
1. Add input to contentEditable
2. Extend textInput to fire for all cases where we currently fire input.
3. Add an action/inputMode property to textInput/input that specifies the
user-action that caused the event.

At some point, we might also want to rename/alias textInput to beforeInput.

Ojan

On Fri, Feb 12, 2010 at 4:33 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Wed, Feb 10, 2010 at 9:11 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>> On Feb 10, 2010, at 4:56 PM, Ojan Vafai wrote:
>>
>> We'd like to implement this event and want to make sure there's no
>> opposition before moving forward. I don't expect this to require huge
>> rewrites to current webkit code, but it will definitely require some
>> plumbing to make it so that all user-gestures that modify the DOM go through
>> this codepath.
>>
>> The proposal is that the input event be fired for any user-gesture that
>> results in a modification to the DOM. This matches the input event for text
>> controls. We'd like to add an 'action' property (open to better names) that
>> indicates what the user-gesture was (e.g. paste, deleteword,
>> undo, inserttext, etc). The goal is to simplify monitoring of changes to
>> rich-text regions and to enable use-cases where the data is stored in a
>> different model than HTML. This is needed so that, for example, an undo
>> operation can be applied correctly on the model as well as the DOM.
>>
>> The beforeinput event would fire before the DOM is modified and is
>> cancelable. I don't think this should be too much more work than adding the
>> input event, an exception might need to be made for IME input here though.
>> Specifically, it might be hard to make IME events cancelable.
>>
>> More details:
>> https://bugs.webkit.org/show_bug.cgi?id=26526
>> Initial whatwg thread:
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020553.html
>> Hixie's response:
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021101.html
>>
>> Sounds like there are basically three changes here:
>>
>> 1) Fire "input" event for contentEditable areas as well as for text-entry
>> form controls.
>> 2) For every case where we'd fire "input" per #1, add a new "beforeinput"
>> event.
>> 3) Add a new InputEvent (or something) interface with an "action"
>> attribute to use for "input" and "beforeinput" events.
>>
>
> Exactly.
>
>
>> All of this seems reasonable on the face of it. Here is some specific
>> feedback:
>>
>> A) We should treat these as three separate changes. Let's do a separate
>> bug, patch and set of tests for each.
>>
>
> Makes sense.
>
>
>> B) Let's go back to the standards groups again (either whatwg or
>> public-html is fine), this time with the additional information that we're
>> planning to implement this soon. I'd like to see if other vendors are at
>> least roughly on board with this direction.
>>
>
> Also makes sense.
>
>
>>  C) "input" is defined as allowing batching of changes (so it can
>> coalesce typing for instance). It seems like "beforeinput" couldn't do that,
>> if it's supposed to fire before the DOM is changed. So there might not end
>> up being a one-to-one correspondence between "beforeinput" and "input"
>> events.
>>
>
> That seems OK to me. It's a bit weird, but it's not unlike having repeated
> keydown events followed by a single keyup event. I'm a bit ambivalent that
> beforeinput loses the batching behavior, but it's necessary for the event to
> be useful. Also, we would need to spec that only input events with the same
> action can be batched. For example, you can't batch input events for an undo
> and a text-entry, but you can coalesce typing.
>
>
>> It seems like it may be tricky to define exactly when it is supposed to
>> fire and how often, especially in the presence of input methods. I'd also
>> like to understand the relationship to the DOM Level 3 Events textInput
>> event: <http://www.w3.org/TR/DOM-Level-3-Events/#event-type-textInput>.
>> Clearly "beforeinput" is more broadly applicable, but when both would fire,
>> which comes first?
>>
>
> I agree that we should be explicit about this, but for any use case I can
> think of, it doesn't matter which fires first as long as we're consistent.
> Conceptually, I think of beforeInput as before any changes have been made to
> the DOM and input being after all changes have been made, so it kind of
> makes sense to me that textInput would fire before input.
>
> In general, input is a superset of textInput, except that textInput also
> fires for changes initiated by script and textInput tells you what text is
> getting inserted. Firing for script-initiated text input seems wrong to me,
> so I'd say we should lobby to drop that requirement from textInput. It might
> be worth considering not adding an InputEvent and instead extending the
> TextEvent <
> http://www.w3.org/TR/DOM-Level-3-Events/#events-Events-TextEvent>. In that
> world, "action" becomes "inputMethod" and "data" is the empty string for any
> inputMethods that are not text-entry. If we did that, I think we should drop
> it and use the input event assuming there's no compat problem. I know Google
> Wave uses textInput, but they would stop using it once we implemented input.
>
>
>> It might be good to roughly hash out the design of "beforeinput" in
>> writing, if we eventually want to take it to standards, so there is some
>> design information besides our implementation to go on.
>>
>
> Agreed. I'll take a stab at that and propose both ideas (having input
> replace textInput and having input live side-by-side with textInput).
>
> Thanks for your feedback. It gives a good starting place. I think the
> hardest part will be the complexity of input methods.
>
> Ojan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100616/dbde0894/attachment.html>