[Bug 12958] 'textinput' event should be renamed to 'input'

https://www.w3.org/Bugs/Public/show_bug.cgi?id=12958

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #14 from Travis Leithead [MSFT] <travil@microsoft.com> 2012-03-16 20:58:23 UTC ---
textinput (as currently spec'd) appears to be merely a drop-in replacement for
"keypress":
* It happens after the relevant character was added
* It happens only for new input (not deletions, etc., which "input" covers
today)

Regarding changing textinput to "beforeinput" or similar: this is non-trivial
and would impact the legacy event order with keypress as I tested in various
UAs. Additionally, (with my implementor hat on) this requires substantial work
to the input pipeline in the browser in order to fire it before and with the
implied ability for it to cancel the input.

In order to resolve this bug, I think there are several options:

1. Leave the spec as-is. As has been noted, textinput in its current
incarnation is a sub-set of the "input" event in all scenarios where it matters
(input/textarea/contenteditable). This reduces churn in this spec, but doesn't
really provide an value over "input" except in the TextInput interface's member
info.

2. Rename the event to "input" as noted in the title. This would require that
this spec harmonize with the definition of "input" in HTML5, that allows
"input" to be fired on any relevant change to the "editing control" (insertions
or deletions). It requires the somewhat tricky definition of an "editing
control" (Aryeh could help me with that), requires me to re-think (and possibly
re-name) what's on the TextEvent interface (e.g., how does "data" work when
you've just deleted something?), and requires HTML5 to update to throwing the
TextEvent (or whatever it's renamed to) to match.

3. Delete the TextEvent and related event type. Keypress will remain spec'd for
legacy reasons, but won't have a default action of textinput. We leave "input"
defined in HTML5 as-is, and let the editing spec define a "beforeinput" if they
want it.

My order of preference at this point is #1 (easiest for me!) > #3 > #2.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 16 March 2012 20:58:29 UTC