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

[Ojan Vafai]

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/20100212/e8605bf0/attachment.html>