Re: textInput --> beforeInput [ISSUE-121]

Hi, Ojan-

Thanks for clarifying your proposal.  I've added this as a Last Call 
comment in our issue tracker as ISSUE-121 [1].  We will continue this 
discussion during LC on the www-dom list and in our telcons.

I'd be very interested in feedback from the other browser vendors on 
this matter.

[1] http://www.w3.org/2008/webapps/track/issues/121

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Ojan Vafai wrote (on 8/27/10 9:08 PM):
> 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
> <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 Friday, 10 September 2010 09:46:48 UTC