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@chromium.org> wrote:
On Wed, Feb 10, 2010 at 9:11 PM, Maciej Stachowiak <mjs@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