It has been suggested before to rename it to "beforeinput".

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.

Currently, "input" event is fired only on <input> or <textarea> except WebKit. If "input" should replace "textinput", it should be fired on contenteditable element too (I think the target should be the editing host element rather than innermost element).

Anyway, textinput event doesn't notify removing character e.g., backspace or delete key. This fact is not useful for web developers, probably.

(In reply to comment #3)
> Currently, "input" event is fired only on <input> or <textarea> except WebKit.
> If "input" should replace "textinput", it should be fired on contenteditable
> element too (I think the target should be the editing host element rather than
> innermost element).

I didn't realize the spec wasn't changed. The spec should clearly change to include input events for contentEditables. Looking back at the thread about this on whatwg@, Ian put off making this change in deference to wanting someone to make a holistic proposal for all of how editing should work. There wasn't actually an opposition to making input events work for contentEditables.

Input event for contenteditable is bug 13118.  It should definitely happen, but I was waiting for responses to bug 13118 comment 12 before speccing it.  The question is when and where we want to fire it, exactly, and how to spec that.  I could do a crude definition (fire it at every editing host every time there's an editing action anywhere in the document) in five minutes, but WebKit's current behavior is much more complicated.  I encourage people to give feedback in bug 13118 about what they'd like to see here.

Assigning to myself to take action on these open bugs.

If the idea is to have a cancelable event that fires before input, I suggest making sure it matches the beforeinput event that I specified for contenteditable.  See bug 13118 comment 33, and the spec, changeset, and test:

http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#methods-to-query-and-execute-commands
http://dvcs.w3.org/hg/editing/rev/a089a5315642
http://dvcs.w3.org/hg/editing/raw-file/tip/conformancetest/event.html

Of course, the use of the EditingBeforeInputEvent interface wouldn't be appropriate for input/textarea, since the .command and .value properties wouldn't make sense.

(No action taken on this bug yet.)

Noting the similarities between ISSUE-121 (https://www.w3.org/2008/webapps/track/issues/121) and this bug.

I need to understand and confirm the current spec'd "input" (HTML5) and this spec's definition of textInput before taking a potential action.

(In reply to comment #7)
> Of course, the use of the EditingBeforeInputEvent interface wouldn't be
> appropriate for input/textarea, since the .command and .value properties
> wouldn't make sense.

I think command and value make perfect sense for textInput as well. "value" would replace textInput's current "data" property and "command" would replace the "inputMethod" property.

As I've said on the mailing list, the list of inputMethods should be truncated to not include things like "handwriting", "multimodal" and "option". They should be a strict subset of the commands used for beforeInput/input events.

If we are going to have "input" and "beforeinput" (lowercase, right?), what is the value in "textinput"?

(In reply to comment #9)
> I think command and value make perfect sense for textInput as well. "value"
> would replace textInput's current "data" property and "command" would replace
> the "inputMethod" property.
> 
> As I've said on the mailing list, the list of inputMethods should be truncated
> to not include things like "handwriting", "multimodal" and "option". They
> should be a strict subset of the commands used for beforeInput/input events.

I think it's confusing to overload .command and .value like that.  I'd make a new BeforeInputEvent or TextBeforeInputEvent interface and add appropriately-named properties like .newValue.  You definitely want to have the beforeinput event for text inputs expose the new value, otherwise there's not much point.

Summary:

I believe the request in this bug is to remove the textInput event, since "input" (HTML5) and "beforeinput" (Editing) cover most of the use cases.

To clarify, the editing spec defines events named "input" and "beforeinput" that are fired for editing.  The HTML5 spec defines an event named "input" (which implements a different interface from the editing "input" event) that is fired for <input>/<textarea>.  No specification currently defines an event named "beforeinput" that applies to <input>/<textarea>.  It would be desirable to have such an event that would be cancelable and would expose the new contents of the <input>/<textarea>, so that authors can control changes to <input>/<textarea>s without having to intercept key events (which is unreliable).

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.

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

My strong preference is #3 > #1 > #2. I don't see any point in keeping around an entirely redundant event, not to mention that we have to do the work of firing it for every keypress.

(In reply to comment #15)
> (In reply to comment #14)
> > My order of preference at this point is #1 (easiest for me!) > #3 > #2.
> 
> My strong preference is #3 > #1 > #2.

My preference is #3 > #2 > #1

Gecko hasn't implemented TextEvent and textinput event yet. So, I don't want to implement them which are said as "redundant".

I think that IE or WebKit needs the textinput event for their internal reason, they can keep it even if it's dropped from D3E spec. Since Gecko hasn't implemented it yet, it never makes more compatibility problems than now.

OK. I've gone with #3 (remove textinput) per consensus. 

I believe all references to that event have been removed as well as the TextEvent interface. Prose has been updated througout the spec as a result.

I believe this action satisfies this comment.

Please review the updated spec:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html?rev=1.217

Thanks!

(Per my process, re-opening so that the bug can rest in the "verified" state until we move the spec to CR.)