Re: textInput --> beforeInput

On Fri, Aug 27, 2010 at 2:20 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> What counts as "any user-action" here? If we're talking about things
> like copy-paste and drag'n'drop then it won't have any of the problems
> that mutations events have.


That's what I had in mind. It would include at least the following: copy,
paste, cut, delete (e.g. from the browser menu), drag, drop, keyboard, undo,
redo, bold/italic/underline (i.e. via ctrl + b/i/u). As Doug pointed out,
the ones of these that do text insertion are already listed for the
textInput event.

By user-action I explicitly do *not* mean script that is executed as a
result of a user-action, e.g. script that modifies the DOM on mousedown
would not fire beforeInput.

On Fri, Aug 27, 2010 at 2:23 PM, Jacob Rossi <rossi@gatech.edu> wrote:

> Yes, I was thinking that myself about it sounding scarily similar to
> mutation events. Though there could be a big difference b/w textInput and
> mutation events if "user-initiated" is well defined. User-initiated action
> would be far less chatty than the general DOM modifications that mutation
> events describe.
>

Exactly. The fastest user-initiated input will be from keyboard
interactions. For each key press right now, we already fire a bunch of
events, including textInput. So, this should have a negligible performance
impact.

In addition to not having the performance problems, beforeInput would not be
an implementation headache and source of crashes the way that mutation
events are. There's one, clear point at which the beforeInput event fires.
The browser code does not need to verify it's assumptions about the state of
the DOM after every modification.

Nonetheless.....correct me if I'm wrong, but it was my understanding that
> this event was mostly to be a "catch-all" for text insertion (from keyboard,
> IME, paste, etc). If that's the case, I think this event as described in the
> spec is acceptable.
>

That is certainly the idea behind the current textInput event. I'm proposing
that we extend it to be more general.

On Fri, Aug 27, 2010 at 2:43 PM, Doug Schepers <schepers@w3.org> wrote:

> Neither copying nor dragging themselves input text, only the end results of
> those "paired" operations, the pasting and dropping.
>
> My conclusion is that Ojan must be talking about extending this beyond text
> and beyond simple insertion.  I am reluctant to change it so dramatically at
> this late stage, but am always willing to listen to implementation
> experience.
>

That is exactly what I'm proposing. In the previous mutation event
discussions, everyone agreed that mutation events are not what you want for
editing. Even the more performant models that Jonas, et al, have proposed
are not what you want for editing. For editing, you want a higher-level API
that is tied to user-actions. beforeInput fits this need and encompasses the
use-cases for textInput.

On Fri, Aug 27, 2010 at 2:17 PM, Doug Schepers <schepers@w3.org> wrote:

> The changes you are suggesting are rather dramatic; they would completely
> change the 'textInput' event.  My personal preference would be to keep
> 'textInput' the way it is, a dedicated event for character data, and if
> necessary, add a different event to cover the cases you're describing.  What
> do you see as the disadvantages of that approach?


I don't see the need for a textInput event if we have the beforeInput event.
They are exactly the same except that beforeInput covers more cases. Stated
differently, textInput is a strict subset of beforeInput, so if we implement
beforeInput, we don't need textInput. Developers that only care about
character data can check the value of the data property and get the same
effect.

The changes are actually not that dramatic in my view:
1. Add more cases to the list of InputMethodCodes:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-ID-TextEvent-InputMethodCode
2. Rename the event
3. Modify the text under
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-texteventsto
change from talking about "text input" to something like "anytime the
user causes the DOM to be modified".
4. Modify
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-TextEvent-datato
specify that the data property is the empty string for inputMethods
that
do not insert plain text.

Currently, WebKit is the only vendor implementing textInput. I can't speak
for the whole project, but of all the people on the project I've talked to
we'd prefer a beforeInput event. It's a natural extension to the textInput
event that meets more use-cases and matches the behavior of the existing input
event <http://www.whatwg.org/specs/web-apps/current-work/#event-input-input>,
which every browser already implements.

Ojan