[webkit-dev] beforeinput and input events for contenteditable/designMode
mjs at apple.com
Wed Feb 10 21:11:21 PST 2010
Thanks for posting about this.
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
> More details:
> 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
3) Add a new InputEvent (or something) interface with an "action"
attribute to use for "input" and "beforeinput" events.
All of this seems reasonable on the face of it. Here is some specific
A) We should treat these as three separate changes. Let's do a
separate bug, patch and set of tests for each.
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.
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. 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? 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev