All native implementations of HTML5 input[type="range"] are broken

Tested input[type="range"] on modern browsers: Firefox 24, Chrome 30, Safari 6, and IE 10. Behavior differed in all four.

Test

Test Variations

Reload this page using the one of the following:

• Vanilla HTML5 (default)
• Webshim Lib polyfill (corrects most issues)
• Webshim Lib polyfill w/replaceUI

Expected Behavior

• input fires on keydown or mousedown/move and only if (potential) value changes
• change fires on keyup or mouseup and only if value changes

Issues

• click: Safari 6 does not focus input[type="range"] element
• click: Firefox 24 fires input needlessly
• mousemove: IE 10 fires change instead of input
• mousemove: IE 10 does not fire input
• mousemove: Chrome 30 and Safari 6 fire both input and change
• mousemove: Firefox 24 and Safari 6 fire input even if there is no step
• mousemove: Firefox 24 continues to fire input even when already at min/max
• keydown: Chrome 30, Safari 6, and IE 10 only fire change
• keydown: Firefox 24 only fires input, continuing to fire even when already at min/max

Comments

Whether element should continue to fire input while at min/max is up to debate, but browsers should agree on behavior.

The next version (1.11.3) of the Webshim Lib fixes the most pressing issues. See Issue #297 and associated commit. Special thanks to Alexander Farkas for (very) actively developing this awesome polyfill library.

See https://github.com/hparra/html5-input-range for this source.

TODOs

• Test Android browsers (yikes)
• Test Safari 7
• Test IE 11
• (Do we need to test Opera?)
• Check/submit bug reports to browsers (chromium, gecko, trident)
• Check/submit bug reports to standards bodies (hixie)
• Discuss UI implementations, styling support