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

[Maciej Stachowiak]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100210/c852c56e/attachment.html>