W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2010

Re: textInput --> beforeInput

From: Jacob Rossi <rossi@gatech.edu>
Date: Fri, 27 Aug 2010 17:23:51 -0400
Message-ID: <AANLkTimfwofTid=Ddx=2Fw38o7hT0SGBhxeJKf7txQSL@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: Ojan Vafai <ojan@chromium.org>, Roland Steiner <rolandsteiner@google.com>, Tony Chang <tony@chromium.org>, www-dom@w3.org, morrita@google.com, danilatos@google.com
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.

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.

-Jacob


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

> Hi, Ojan-
>
> Ojan Vafai wrote (on 8/27/10 4:34 PM):
>
> Is there consensus on the following changes?
>>
>> 1. Rename textInput to beforeInput.
>>
>
> That's only really relevant if we are going to make textInput into a
> general insertion event, rather than one just for text.
>
>
>
> 2. Fire beforeInput for any user-action that modifies the DOM, not just
>> actions that cause text to get inserted.
>>
>
> That's more like a mutation event, not a 'textInput' event, and mutation
> events are pretty widely reviled by implementers (though useful when
> implemented); they seem to be difficult to implement efficiently.  We have
> deprecated Mutation Events in DOM3 Events, though there are still going to
> be implementations for a while.
>
> There are proposals to replace Mutation Events with a new, more efficient
> notification mechanism... I think what you are describing may fit better
> with that model.
>
> 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?
>
>
>
> Looking at the history of this thread, it seems that everyone who has
>> commented agrees with making these changes.
>>
>
> As far as I can see, the only person who specifically commented on the name
> change was Jacob Rossi, who said [1]:
> [[
>
> I don't particularly care. But since this event only applies to
> character data I see no problem with it as named (textInput).
> ]]
>
> I didn't see comments from any other implementers, such as Mozilla,
> Microsoft, Opera, or Apple; I would like to hear from them before making any
> change.
>
> [1] http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0087.html
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
Received on Friday, 27 August 2010 21:24:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:05 GMT