W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

Re: [DOM3 Events] textInput event should be removed

From: Ojan Vafai <ojan@chromium.org>
Date: Mon, 7 Nov 2011 16:51:44 -0800
Message-ID: <CANMdWTtVc1o6th=Evu5bzP98bAY7MNxPsZt=ELEKxu+cydHPuQ@mail.gmail.com>
To: www-dom@w3.org, Olli Pettay <Olli.Pettay@helsinki.fi>, Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>
Turns out this was already filed:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12958.

On Mon, Nov 7, 2011 at 4:42 PM, Ojan Vafai <ojan@chromium.org> wrote:

> I'm not sure when, but at some point, it seems the textInput event changed
> from being before the DOM was modified to being after the DOM was modified.
> This means that the textInput event is now a strict subset of the input
> event. We should instead remove the textInput event from the spec and add
> the data and inputMethod properties to the existing input event.
>
> Every browser already implements the input event and restricting to only
> text inserting inputs is a single if-statement, 'if (event.data === "")'. I
> don't see the benefits of having a special event. The cons are clear to me.
> It's yet another event we fire on every key press, it broadens the platform
> and it hurts performance (e.g. if you listen to both the textInput and
> input events you need to do all the work of firing an event twice).
>
> To add to the complication, the two existing implementations are fairly
> incompatible. WebKit fires the event before the DOM is modified and matches
> the case-sensitive "textInput". IE9 fires the event after the DOM is
> modified and matches the case-sensitive "textinput".
>
> The HTML spec already covers the input event, so my proposal is just to
> remove the textInput event from DOM3 Events. Separately, we can get the
> data and inputMethod properties specified in HTML.
>
> Ojan
>
Received on Tuesday, 8 November 2011 00:52:41 GMT

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