Search jQuery

jQuery Forum

HTML5 `oninput` event

in Developing jQuery Core • 5 years ago

I previously opened a ticket to try and get some support for this event in jQuery 1.7, but it was voted against for several reasons. Being a Stack Overflow regular, I very often see answers recommending `keyup` to detect text input. This is bad for many reasons, not least of which are:

No support for drag/drop, spellchecker corrections, cut/paste, undo etc.
keyup only fires when, yes, you lift your finger off the key. This results in a slight delay before modifications to the input's value are applied.
key events require extra code to ignore non-character keys, like tab and arrow keys. Forgetting to ignore these keys can lead to very poor accessibility, like blocking tab focus, shift+arrow key selections and moving the caret with the arrow keys.

To provide a solution, I wrote up a plugin which attempted to resolve cross browser differences and implement the `oninput` event in older browsers. Whilst this worked reasonably well at implementing the event in unsupported browsers, it failed to mitigate several issues with existing implementations. It didn't support live binding for `onpropertychange` in Internet Explorer either.

Eventually, I came up with an entirely different approach that uses graceful degradation and ditches detection completely. This approach binds wildly to many different input events, taking advantage of event order so that as much of the oninput functionality as possible can be implemented. This new approach also allows live binding/delegation by listening for `onfocusin`, `onmouseover` and `ondragstart` on elements further up the tree. When an input/textarea element fires any of these events, they propagate to the delegated element and it sets up the `onpropertychange` handler.

There's just 1 significant downside to the new approach I took. I had to rename the special event to "input2" so that it didn't clash with "input" in browsers that already supported it. I'm not sure if technical limitations with the jQuery special event model prevent it from being possible or if it's just a lack of understanding on my part. However, if this event were to become natively supported in jQuery core, I believe it could be worked around rather easily.

There's another, smaller downside that I believe will have very little impact on most (if not all) developers. Changing `element.value` in script will trigger an `onpropertychange` in Internet Explorer and fire the resulting event. This could possibly be worked around for $.fn.prop/$.fn.attr, but as I said I think the impact would be minimal.

I'd like to re-propose this for inclusion in jQuery core, but I'd like to get some thoughts first. I've come across many sites with accessibility issues due to onkeyup and I think that jQuery is in a better position to <i>change the web</i> than I am. Also, if anyone has any ideas on how I could work around the event naming limitation, that would be great.

Replies(6)

dave.meth..

Re: HTML5 `oninput` event

5 years ago

We're making a strong effort to reduce the size of jQuery over the next few versions, so new features will need to be nearly universally needed before we'd consider them for inclusion. I have not needed the functionality offered by the input event in most of the pages I've written, so it's not likely to be a universal need.

There's nothing wrong with having people who want the input event include this code as a plugin. The fact that you've been able to find better ways to do it shows that it might have been premature to include a solution before this. It would be better to let this functionality mature by itself, and prove that many people need it, by making it a plugin.

As for the code, have you checked that this works in 1.7b2? There are some new features that might help what you're trying to do, but also a few potential incompatibilities. One thing you could do with the new special.handle hook is set a flag to avoid recursing in the case of IE onpropertychange. Sorry that there is no doc at the moment, but you can see how it is used in the mouseover/mouseenter hook and I'll be glad to answer questions.

If you're trying to exactly recreate the input event, the best way to do that would be to determine if it's natively supported, using feature detects similar to the ones in support.js. If it's not there, your special event handler should attach its events and do magic. If input events are supported it can just return false and let the browser do all the work. That's generally the way we'd want to support it in core, rather than create a new non-standard event name.

> This approach binds wildly to many different input events

Yeah, it's a very common pattern for simulating other events and has its pro/cons since the other events don't always occur in the same place as the one you're trying to simulate. While I was working on 1.7 improvements I added the event order information to the delegatetest.html file in jquery/test, that might help as a starting point when deciding how to fire the events.

Andy E

Re: Re: HTML5 `oninput` event

5 years ago

Thanks for the reply, I really appreciate the advice you've given. I released my improvements for the plugin earlier today on my website:

http://whattheheadsaid.com/projects/input-special-event

I understand that you're trying to make jQuery smaller, it is somewhat of a behemoth. Unfortunately, feature detection just doesn't cut it for this event, there's too many bugs in early implementations from browsers. I think core could make it possible to use the original event name - perhaps I could too, but I'm just not sure how.

I have not needed the functionality offered by the input event in most of the pages I've written, so it's not likely to be a universal need.

You might think that this is not a universal need but very often developers need this event without even realizing it. Because it's a fairly new thing there's just not enough awareness and those developers think that key events are the only option available to them. On Stack Overflow, for instance, there's a boatload of questions exactly like this:

http://stackoverflow.com/questions/6153047/jquery-detect-changed-input-text-box

Where almost all the answers are "use onkeyup". This is exactly the kind of thing that leads to the sort of accessibility issues I was talking about in my original post - such as the problem where so many (inc high profile) sites automatically move focus to the next field after you complete the current, but if you made a mistake then you can't shift+tab back into it. Barclays online banking site is one example that immediately springs to mind, but I bet we've all experienced this or a similar problem. Of course, there are workarounds in key events too but, all too often, these problems don't even occur to the developer.

I thought that this is exactly the kind of thing jQuery did - take something that was awkward and unwieldy and turn it into something much easier to work with, much like the mouseenter and mouseleave events that aren't implemented in many browsers. I can understand that you may want to see how big adoption of a plugin is first, but in all honesty, my blog just isn't big enough and (as I mentioned before) developers don't search for a solution to a problem they don't realize they have.

dave.meth..

Re: HTML5 `oninput` event

5 years ago

> I thought that this is exactly the kind of thing jQuery did - take something that was awkward and unwieldy and turn it into something much easier to work with

True, but that is also what jQuery UI and jQuery plugins do in general. There is no reason that it all has to be in core. If you were writing an advanced form handling plugin it might be ideal for that, you could use the input event if it were present and backfill with other methods if it wasn't.

Once code gets into core it is much more difficult to alter because change need to be synchronized to core releases. Also, people want to depend on it always being there and its behavior not changing, EVER. Yet people also want new features, and we still have to fix serious cross-browser bugs. That's why the size of core has gone up so much, and we need to draw the line. You've mentioned that browser implementations of the input event aren't consistent or stable, if that's the case then the best path may be to wait until they stabilize before trying to tackle them in core.

> such as the problem where so many (inc high profile) sites automatically move focus to the next field after you complete the current, but if you made a mistake then you can't shift+tab back into it.

I am not a fan at all of UI ideas like three fields for phone number where it automatically tries to advance the focus as you are typing, they end in sorrow regardless of the underlying browser technology. It's just a bad idea no matter what.

rdworth

Re: Re: HTML5 `oninput` event

5 years ago

> I thought that this is exactly the kind of thing jQuery did - take something that was awkward and unwieldy and turn it into something much easier to work with

True, but that is also what jQuery UI and jQuery plugins do in general.

I'm glad that Dave brought this up, because I was just about to. jQuery UI seems like the perfect place for super-common-but-not-jquery-core-essential-for-all functionality such as this.

> such as the problem where so many (inc high profile) sites automatically move focus to the next field after you complete the current, but if you made a mistake then you can't shift+tab back into it.

I am not a fan at all of UI ideas like three fields for phone number where it automatically tries to advance the focus as you are typing, they end in sorrow regardless of the underlying browser technology. It's just a bad idea no matter what.

Wholeheartedly agree. For sure my biggest pet peeve of all web forms. Quite a different approach than the topic of this thread (and I don't mean to OT), but I feel like we've got a pretty good solution for this particular concern in our Mask widget, currently in development as part of jQuery UI:

http://wiki.jqueryui.com/w/page/12137996/Mask

demos: http://view.jqueryui.com/mask/tests/visual/mask/mask.html

Andy E

Re: HTML5 `oninput` event

5 years ago

rdworth, I didn't realize jQuery UI provided special events. I took a quick look at your mask plugin - it breaks in IE 8 and lower for dropping text into the box, kind of an edge case but you could plug it by cancelling


      ondragstart

and handling


      ondrop

, or handling


      onpropertychange

for the value property. I'd also expect it to break in Opera 10.x and lower for cut & paste. It also prevents shift+cursor key text selection.

I am not a fan at all of UI ideas like three fields for phone number where it automatically tries to advance the focus as you are typing, they end in sorrow regardless of the underlying browser technology. It's just a bad idea no matter what.

Me either. Unfortunately, though, we don't get to decide on the behaviour of these sites. I've never been a fan of mask-as-you-type inputs either, to be honest, they break Ctrl+Z/Undo and come with a whole host of accessibility issues that never seem to get worked around. Much better to have a good validation plugin and, if you really want it, mask-on-blur.

Thanks for your time, guys, I really appreciate it.

rdworth