Re: textInput --> beforeInput

On 08/28/2010 04:08 AM, Ojan Vafai wrote:
> 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.

So I don't understand at least copy nor drag. Those aren't "input", they
don't generate anything to the DOM (or anonymous DOM).
So whether the event name is beforeInput or textInput, those cases
just don't belong to this event.

IMO, textInput sounds better for what is meant for; to have an event
which is dispatched before entering some data.

paste and drop may actually have some problems with current textInput.
What if the data isn't just text, but some markup.

-Olli


>
> 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
> <mailto: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
> <mailto: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
> <mailto: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-textevents
> to 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-data
> to 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

Received on Wednesday, 15 September 2010 19:20:35 UTC