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:
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
-- Hector Parra, @hgparra