Refactor fluid.slider to be able to use native <input type="range"> instead of jQuery UI slider widget
Description
Environment
Activity
Justin Obara July 11, 2016 at 6:19 PM
Merged infusion-docs PR ( https://github.com/fluid-project/infusion-docs/pull/93 ) at f5af742ba3f4f4099d8027c391de14ab4e33074c
Cindy Li July 5, 2016 at 2:12 PM
The pull request https://github.com/fluid-project/infusion/pull/724 has been merged into the infusion master branch at f48d47f9144a91bd47c326da03dd4e3b92dd4396
Alan Harnum April 21, 2016 at 1:37 PM
Thanks that's really good information.
Jonathan Hung April 21, 2016 at 12:39 PM
the accessibility of the range slider is very good. I've also tested it with JAWS, NVDA, VoiceOver on Safari, IE 11/Edge, Firefox, Chrome and it works really well.
The only exception being in IE11 - I ran into a quirk where the slider appeared as text input fields if the content was loaded directly from the filesystem and not served via a server. This was true for me in VirtualBox, it may not be an issue on a native machine.
You can play with slider implementation we have for PhET here: https://jhung.github.io/john-travoltage-html/
Antranig Basman April 19, 2016 at 9:47 PM
Sounds good, - at a guess from your description, the problem may lie in the following block of code - https://github.com/fluid-project/infusion/blob/master/src/lib/jquery/ui/js/jquery.ui.slider.js#L166 - since it seems that the slider follows a "roll your own" approach for binding to mouse events rather than depending on the (presumably) much more well-tested jQuery UI draggable library. It would probably take us longer to research the problem and fix it (or, alternatively, go through a cycle of jQuery + jQuery UI upgrades) than it would to revert to the native HTML5 range control, so I'm in favour of the latter if the accessibility story is good as it seems to be.
Details
Assignee
Alan HarnumAlan HarnumReporter
Alan HarnumAlan HarnumComponents
Priority
Major
Details
Details
Assignee
Alan HarnumReporter
Alan HarnumComponents
Priority
Major
At the time of the implementation of the original preferences framework components, the new HTML5 Form Additions were not at a standard level of support in current browsers, so the jQuery UI slider was used to implement the fluid.slider component.
In reviewing FLUID-5698 it seems the use of the jQUI slider is one barrier to being able to remove some or all of the redundant Javascript from the HTML for the SeparatedPanelPrefsEditorFrame that's included in an <iframe>. So I propose trying to replace the jQUI-based slider with one based on the native (and now apparently fully supported in all current browsers) "range"-type input.
Using a native form control obviously has a number of other potential advantages besides the improved performance and behaviour we'll get.