A common UI pattern for a range slider is to allow the user to move the slider and display the value of it somewhere on the page, changing the displayed value as the user moves the slider.
I think the expected behaviour in such a case is that the value should display instantly, as the user is moving the slider, rather than the page waiting for the slider to finish moving before the displayed value is updated. I suppose there could be cases where you prefer a delay over instant results, but I think the expected behaviour is to display the results instantly.
As you’ll see in the videos below and in your own testing, the behaviour of the
input event compared to the
change event is not exactly the same in different browsers when applied to a range slider.
Let’s look at how these events behave in the different browsers. The code I’ll be using is embedded in the CodePen example below:
input to see the differences I’ll be discussing. The results described are observed on OSX and Windows 7.
Note: Opera is equivalent to Chrome in these tests because it now has the same rendering engine.
oninput in Chrome
- Works as expected, the
inputevent fires immediately when the slider is adjusted, which is demonstrated by the value changing on the page instantly.
- Focusing and adjusting the slider with the keyboard has the same result.
onchange in Chrome
changeevent does not fire immediately, demonstrated by the fact that the value on the page does not change until the slider stops moving.
- Keyboard interaction, however, is the same as
oninput, with the value on the page updating immediately.
oninput in Firefox
- Same results as
oninputin Chrome; changes happen immediately.
- Keyboard results the same, changes appear immediately.
onchange in Firefox
- Same results as Chrome; the value doesn’t change on the page until the slider stops moving.
- When moving the slider with the keyboard, the value does not update until the slider is blurred, or unfocused. This is the only difference from the behaviour in Chrome.
oninput in IE11
oninputis not recognized at all when used on a range slider. The same event, however, does fire when used on a text input.
oninputdoesn’t fire, the value of the slider is displayed in a native tooltip, which doesn’t happen on the other browsers.
- The keyboard likewise has no effect on the value and the native tooltip is not displayed.
onchange in IE11
- Works the same way as
oninputin Chrome and Firefox; the value changes immediately while the slider is still moving.
- Keyboard results are the same, the value updates immediately.
What’s the Correct Behaviour?
The WHATWG spec describes the expected behaviour as follows:
inputevent fires whenever the user has modified the data of the control. The
changeevent fires when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the
inputevent comes before the corresponding
changeevent (if any).
The same description is found in the W3C version of the spec.
oninput, Chrome and Firefox have the correct behaviour with both mouse and keyboard interaction. But Firefox seems to have the most accurate behaviour for
As shown in the quote above,
onchange should always fire after
oninput, so the fact that Firefox waits for the range slider to lose focus before firing the event (for both mouse and keyboard) seems to be the correct behaviour. Chrome does not wait until the control is unfocused when using the keyboard, but it does so with the mouse.
IE11, of course, is completely wrong on two counts: It doesn’t recognize
oninput when applied to a range slider and it responds to
onchange as if it was
oninput, firing the event immediately instead of waiting until the slider stops moving or loses focus.
As a side point here, the HTML4 spec seemed to define the behaviour a little more clearly:
onchangeevent occurs when a control loses the input focus and its value has been modified since gaining focus.
Though when that was written, there was no such thing as
type="range" for form inputs.
Sources and Bug Reports
There has been discussion on this behaviour in the bug trackers for the various browsers, and I believe the wording in the spec was updated to be less ambiguous — although I still feel that it’s not 100% clear if Firefox’s keyboard behaviour is the correct one.
Here are some relevant links in addition to the ones provided in the article above:
- Firefox bug report – Closed as “invalid” since Firefox’s behaviour is correct.
- IE11 bug report on missing
inputevent, still unresolved.
- Chrome bug report which I filed myself to see if the different keyboard behaviour can be corrected to agree with Firefox.
- W3C bug report, which attempts to make the spec less ambiguous.
- change event on MDN, which explains that “different browsers do not always agree whether a
changeevent should be fired for certain types of interaction.”