Hi Ojan,
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
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.
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.
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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
