Side navigation
#9121 closed feature (wontfix)
Opened May 05, 2011 01:20PM UTC
Closed July 12, 2011 03:04PM UTC
Last modified March 14, 2012 06:46AM UTC
Add support for the HTML5 `oninput` event
| Reported by: | Andy E | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | event | Version: | 1.6 |
| Keywords: | 1.7-discuss | Cc: | |
| Blocked by: | Blocking: |
Description
All the edge major browsers appear to support the oninput event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input.
A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of onkeyup for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately.
The following fiddle demonstrates the event (and the plugin) very basically: All it does is copies the text as you type, but as you can tell, there is no visual delay.
Further reading:
All it does is copies the text as you type, but as you can tell, there is no visual delay.
Further reading:
Attachments (0)
Change History (26)
Changed May 05, 2011 01:31PM UTC by comment:1
| resolution: | → wontfix |
|---|---|
| status: | new → closed |
Changed May 22, 2011 07:08PM UTC by comment:2
| resolution: | wontfix |
|---|---|
| status: | closed → reopened |
This was suggested for 1.7.
Changed May 22, 2011 07:27PM UTC by comment:3
| keywords: | → 1.7-discuss |
|---|
Nominating ticket for 1.7 discussion.
Changed May 23, 2011 12:48AM UTC by comment:4
| description: | All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/ → All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input.\ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately.\ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/ |
|---|
-1, Let's start as a plugin so that we can assess the limitations.
Changed May 23, 2011 04:40AM UTC by comment:5
-1, plugin
Changed May 24, 2011 01:01AM UTC by comment:6
| component: | unfiled → event |
|---|---|
| description: | All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input.\ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately.\ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/ → All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/ |
| priority: | undecided → low |
| status: | reopened → open |
Changed May 24, 2011 09:47PM UTC by comment:7
-1, Plugin first.
Changed May 25, 2011 09:36AM UTC by comment:8
I wrote a plugin (as I said in the original filing). I also discuss some of the limitations in the same post.
http://whattheheadsaid.com/projects/input-special-event
Also, I've just noticed a bug in IE 9 where the oninput event doesn't fire when the backspace or delete keys are pressed - my plugin doesn't yet deal with that.
Changed June 03, 2011 02:00PM UTC by comment:9
| description: | All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/ → All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input.\ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately.\ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/ |
|---|
-1, Would be good to prove as a plugin.
Changed June 04, 2011 09:10AM UTC by comment:10
I'm not sure I understand this, do you mean an "official" plugin of some sort, or are people just not reading the ticket properly? Despite the ticket body and my other comment saying "I have already provided a plugin", everyone is still saying "-1 plugin first".
This has left me rather confused.
Changed June 04, 2011 12:55PM UTC by comment:11
| description: | All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input.\ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately.\ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/ → All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: |
|---|
hey Andy,
The comments you see are votes by core, bus and ui team members - this ticket was elevated to 1.7 proposal status.
As for official plugin, that's not likely - but if you write a solid plugin that has a high adoption rate, there is a better chance for core consideration, though rare
hope that cleared things up for you. Feel free to ask any other questions!
Changed June 05, 2011 09:47PM UTC by comment:12
| description: | All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: → All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/. All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ http://www.whatwg.org/specs/web-forms/current-work/#the-change \ http://www.whatwg.org/demos/2008-sept/widgets/ \ http://blog.danielfriesen.name/2010/02/16/html5-browser-maze-oninput-support/ \ http://whattheheadsaid.com/2010/09/effectively-detecting-user-input-in-javascript http://jsfiddle.net/B459a/. All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ http://www.whatwg.org/specs/web-forms/current-work/#the-change \ http://www.whatwg.org/demos/2008-sept/widgets/ \ http://blog.danielfriesen.name/2010/02/16/html5-browser-maze-oninput-support/ \ http://whattheheadsaid.com/2010/09/effectively-detecting-user-input-in-javascript |
|---|
+0, Seems the full ticket proposal got truncated and the fiddle and links got cut off - I've amended the description accordingly, and taken a look at your plugin. At the moment, it seems to have a number of shortcomings - the lack of support for delegation, for one, so it seems there's more research necessary into the problem. I like the idea of providing a cross-browser solution to this, however - have you heard of much adoption of the plugin thus far?
Changed June 06, 2011 09:28AM UTC by comment:13
I know several people have commented on my blog post and I regularly direct people to it from Stack Overflow. The plugin is the most visited page on my blog, but I only installed analytics a couple of weeks ago so there's not really enough data to say anything solid.
Telling people doesn't ''always'' work, though; there are a lot of confused individuals out there promoting events like ''keyup'' for input counters and the like. Most jQuery plugins detecting input use ''keydown'', ''keypress'' or ''keyup'' too. ''input'' would serve them much better, catching cutting, pasting, dropping, spell checker corrections and others. IMO, having the event supported by jQuery would immediately increase awareness of the event, improving the quality of input detection scripts around the web.
As for delegation, it would work for the browsers that support the event natively, since it bubbles but, as for the older browsers (namely IE6-8), it would be difficult to get the event working for "future elements". I did think about this to some extent, though, and may be able to come up with a solution based on ''focusin'' or ''mouseover'' -- when an input element receives either event it is checked against the delegate selector and then the ''input'' event is applied to the element if necessary.
Changed June 06, 2011 12:37PM UTC by comment:14
| description: | All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: http://jsfiddle.net/B459a/. All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ http://www.whatwg.org/specs/web-forms/current-work/#the-change \ http://www.whatwg.org/demos/2008-sept/widgets/ \ http://blog.danielfriesen.name/2010/02/16/html5-browser-maze-oninput-support/ \ http://whattheheadsaid.com/2010/09/effectively-detecting-user-input-in-javascript http://jsfiddle.net/B459a/. All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ http://www.whatwg.org/specs/web-forms/current-work/#the-change \ http://www.whatwg.org/demos/2008-sept/widgets/ \ http://blog.danielfriesen.name/2010/02/16/html5-browser-maze-oninput-support/ \ http://whattheheadsaid.com/2010/09/effectively-detecting-user-input-in-javascript → All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ \ \ \ All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ \ \ \ |
|---|
Mathias also has an implementation: http://mathiasbynens.be/notes/oninput
I believe he is going to have this, with unit tests, on github today.
Changed June 06, 2011 01:02PM UTC by comment:15
OK, so I managed to put together an experimental version of the plugin that supports ''delegate()''. It only increased the size by a few lines.
http://jsfiddle.net/AndyE/pLUY4/1/
I haven't added this to my blog post yet because I just realized I forgot to unset some data in the event teardown and I also need to implement a workaround for the bug in IE 9 where it doesn't fire ''oninput'' for backspace or delete. I've run out of time at the moment, though, so just posting what I've got so far.
Changed June 06, 2011 01:07PM UTC by comment:16
| _comment0: | Note that my plugin is very barebones by design. jQuery probably needs something more consistent across browsers. \ \ I just wanted a simple, minimal solution that gracefully degrades in older browsers. (Also, just like Andy’s special event plugin, it doesn’t support event delegation.) → 1307365684825052 |
|---|
Note that my plugin is very barebones by design. I just wanted a simple, minimal solution that gracefully degrades in older browsers. jQuery, on the other hand, probably needs something more consistent across browsers.
Changed June 06, 2011 02:54PM UTC by comment:17
| description: | All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ \ \ \ All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ \ \ \ → All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input.\ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately.\ \ The following fiddle demonstrates the event (and the plugin) very basically: All it does is copies the text as you type, but as you can tell, there is no visual delay.\ \ Further reading: \ \ \ \ \ All it does is copies the text as you type, but as you can tell, there is no visual delay.\ \ Further reading: \ \ \ \ \ |
|---|
-1, perhaps a good next step would be showing how this would improve some jQuery UI plugins
Changed June 07, 2011 06:26PM UTC by comment:18
| description: | All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input.\ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately.\ \ The following fiddle demonstrates the event (and the plugin) very basically: All it does is copies the text as you type, but as you can tell, there is no visual delay.\ \ Further reading: \ \ \ \ \ All it does is copies the text as you type, but as you can tell, there is no visual delay.\ \ Further reading: \ \ \ \ \ → All the edge major browsers appear to support the `oninput` event, which fires for text input into an element. The event itself is superior to key events because it fires for all forms of text input. \ \ A while ago, I wrote a plugin that normalizes the event for browsers that don't support it, notably IE6-8. I believe this works well enough, despite a few limitations. Despite the existence of this event (and the plugin), every day I see people recommending the use of `onkeyup` for acting on user input. Integrating this event into jQuery may help these users learn to handle user input more appropriately. \ \ The following fiddle demonstrates the event (and the plugin) very basically: All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ \ \ \ All it does is copies the text as you type, but as you can tell, there is no visual delay. \ \ Further reading: \ \ \ \ \ |
|---|
No reliable feature detect is available according to https://github.com/Modernizr/Modernizr/issues/210
Changed June 08, 2011 09:49AM UTC by comment:19
dmethvin,
That's not the case. According to several users on that ticket, the bug has been fixed in the latest version of Firefox. Aside from that, it's detected by my plugin using a few fallback techniques, including a "last resort" technique that works in Firefox, which was outlined on Daniel Friesen's blog.
http://blog.danielfriesen.name/2010/02/16/html5-browser-maze-oninput-support/
scott.gonzalez,
The only jQuery plugin that appears (from a glance) to make use of key events for text input is Autocomplete. As far as I can tell, it doesn't support spell-checker corrections, cut, paste, undo, redo, drag and drop, voice control/speech-to-text or any other form of text input.
Supporting the event would be a boost for Opera, which doesn't support several text input events that other browsers do like cut, paste, textInput, etc.
Changed June 10, 2011 09:27AM UTC by comment:20
The input event is not supported for textareas on Safari < 5. You'll need to fall back to the DOM 3 textInput event, which Safari does support from 3.1 (and even then you're not covering Safari 3.0).
Changed June 10, 2011 09:28AM UTC by comment:21
Previous comment is mine.
Changed June 10, 2011 11:26AM UTC by comment:22
That's a good point, Tim. I believe Safari 3.0 supports ''oncut'', ''onpaste'' and drag/drop events (assuming you cancel the ''ondragstart'' event for the text box) -- all that's needed is to detect the ''bug'' where ''oninput'' doesn't fire for textarea elements. I'll give it some thought and see if I can come up with a solution.
As for Safari 3.1 and later, you could bind to just ''textInput''. Or bind to both events and set a flag to suppress one when the other fires (depending on order of precedence).
If I get some time, I'll have a crack at a solution.
Changed June 11, 2011 10:49PM UTC by comment:23
Right, got a bit of time and I've come up with a proof of concept that appears to work well in all browsers:
http://jsfiddle.net/AndyE/sdkBs/
It works by binding to all known input events on ''<input>'' and ''<textarea>'' elements, but utilizes only the most "useful" event which is usually one of the following:
- ''input'' in browsers that support it (except IE9 due to the delete bug)
- ''onpropertychange'' in all versions of IE
- ''textInput'' on ''<textarea>'' elements in Safari < 5
I've tested it on ''<textarea>'' in Safari 3.0 and 4.05. It works with delegate using the same method as before - binding to ''mouseover'', ''focusin'' and ''dragstart'' on the delegated element and binding to ''<input>'' and ''<textarea>'' elements that fire any of those events. ''keydown'' might also be required for older browsers that don't support ''focusin'' - I need to do a little research to see if this is necessary.
One of the interesting advantages of this approach is that it trades in feature detection for graceful degradation - no more awkward checks in Firefox to find out if the event is supported and no more false positives from Safari <5.0 on the ''<textarea>'' element.
If you ask me, the bugs in vendor implementations makes it all the more important that one of the major libraries normalizes this event for us. It was introduced in HTML5 to fill an obvious deficiency in input detection and, with the influence jQuery has with web developers, including support for it will help spread the word that input detection doesn't have to stop at the keyboard.
Changed June 12, 2011 12:28PM UTC by comment:24
It was late last night when I wrote that, so I forgot to add that IE 9 does use the ''input'' event, except for when the bug is in effect and it doesn't fire for the backspace or delete keys.
Also, because the custom version of the event relies on the ''input'' event, I had to rename the special event to ''input2'' - haven't yet figured how to work around this with the jQuery event api.
Changed July 12, 2011 03:04PM UTC by comment:25
| resolution: | → wontfix |
|---|---|
| status: | open → closed |
Per the 1.7 meeting this won't be implemented.
Changed December 07, 2011 05:04PM UTC by comment:26
#10971 is a duplicate of this ticket.
This is quite a bit of code so I don't think we're in a hurry to include it into core. I'd suggest making it available as a plugin for now. If you'd like to suggest it for 1.7:
https://spreadsheets.google.com/viewform?hl=en&authkey=CPmgicsO&formkey=dG0yTEs2ZTFWQUhDRUp5dzRyc3NwV2c6MA#gid=0