Bug 12958 - 'textinput' event should be renamed to 'input'
'textinput' event should be renamed to 'input'
Status: VERIFIED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events
unspecified
All All
: P1 major
: ---
Assigned To: Travis Leithead [MSFT]
public-webapps-bugzilla
: LC, reviewerSatisfied
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-15 18:10 UTC by Mounir Lamouri
Modified: 2012-03-21 11:30 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mounir Lamouri 2011-06-15 18:10:45 UTC
The 'input' event as defined in the HTML specifications is widely implemented [1] but DOM3 Events specify an event named 'textinput' which seems to be exactly what 'input' event tries to do. Couldn't the spec rename this event to 'input'?

[1] Successfully tested on Gecko, Presto and Webkit. Didn't try IE.
Comment 1 Anne 2011-06-17 16:04:41 UTC
It has been suggested before to rename it to "beforeinput".
Comment 2 Ojan Vafai 2011-11-08 00:51:04 UTC
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.
Comment 3 Masayuki Nakano 2011-11-09 02:03:26 UTC
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.
Comment 4 Ojan Vafai 2011-11-09 02:42:15 UTC
(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.
Comment 5 Aryeh Gregor 2011-11-09 14:20:20 UTC
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.
Comment 6 Travis Leithead [MSFT] 2012-03-08 21:16:49 UTC
Assigning to myself to take action on these open bugs.
Comment 7 Aryeh Gregor 2012-03-12 17:13:08 UTC
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.
Comment 8 Travis Leithead [MSFT] 2012-03-12 19:54:28 UTC
(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.
Comment 9 Ojan Vafai 2012-03-13 02:47:19 UTC
(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.
Comment 10 Anne 2012-03-13 07:51:31 UTC
If we are going to have "input" and "beforeinput" (lowercase, right?), what is the value in "textinput"?
Comment 11 Aryeh Gregor 2012-03-13 18:36:21 UTC
(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.
Comment 12 Travis Leithead [MSFT] 2012-03-16 00:11:47 UTC
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.
Comment 13 Aryeh Gregor 2012-03-16 14:29:49 UTC
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).
Comment 14 Travis Leithead [MSFT] 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.
Comment 15 Ojan Vafai 2012-03-17 01:38:37 UTC
(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.
Comment 16 Masayuki Nakano 2012-03-18 00:50:06 UTC
(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.
Comment 17 Travis Leithead [MSFT] 2012-03-20 01:25:03 UTC
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
Comment 18 Travis Leithead [MSFT] 2012-03-20 17:35:22 UTC
Thanks!

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