5 years ago

The HTML5 Input Event

In the DOM a special event occurs on an <input> or <textarea> element known as the change event [1] [2]. The change event gives a developer the ability to catch input changes. However, it falls short when instant feedback is needed because it will only trigger once the input has lost focus. Immediate feedback could be handled using the keydown or keyup events. Those events are costly (happening often and requires the code to keep state to know of changes actually occurring) and are potentially buggy due to extra logic needed.

With the advent of HTML5’s ubiquity (IE9+) there are new events that solve the input problem. One of them is the input event [3] [4]. This event is intended to trigger on input, which delivers immediately after the user takes an action. The event triggers on any change including cut, paste, drag and keyboard interactions. When it works, it simplifies the interactions with forms and text editing.

https://gist.github.com/geedew/2876f7d17ca9de32b85f

In the HTML4.01 world, an example app could have a form that wants to show password strength. It’s easy enough to use an onChange handler, but then the user would only see the meter update once the field loses focus, often by submitting the form. To counter that behavior, an onKeyup handler is attached to catch the keyboard events as they type. This however means paste events would not fire, or JS value events (like those from a password manager). So it still isn’t going to always work and the keyup is going to fire for pointless things like cursor movement via arrow keys.

In HTML5 then, the same example is implemented with the single onInput handler. Each of these cases are handled exactly as expected and when expected. Unless the user is using IE9 which unfortunately does not trigger onInput during deletion events like backspace, delete, cut or drag [3] [5].

Further Reading