This repository was archived by the owner on Oct 8, 2021. It is now read-only.
This repository was archived by the owner on Oct 8, 2021. It is now read-only.
Slider & accidental touch #4067
Closed
Description
Having a longer from that requires scrolling, sometimes when scrolling the page and touching too close to a slider also modifies the value of that slider.
Ideally slider objects should evaluate the direction of the drag movement, and if it doesn't match the sliders orientation those drags should be ignored.
Activity
toddparker commentedon Apr 19, 2012
Can you provide more details on what scenarios and devices you're seeing this issue? Unless I start a drag on top of the handle or tap the track, the slide doesn't seem to move.
gknops commentedon Apr 19, 2012
Thanks for taking the time to look into this!
This is on iPhone, iOS 5.1. In my case I need a list of 12 sliders. For the same of UI compactness I use attributes and CSS to hide the textual range control and the label, and also made the sliders wider.
In this context it is easy to accidentally touch a slider while scrolling.
To avoid accidental slider changes I propose two changes:
a) an extra option controlled via a range control attribute that causes sliders to only respond to touches to the handle, not to a tap anywhere on the track.
b) the slider should evaluate at the directionality of the initial drag, if that doesn't match the sliders orientation, no change should occur and the remainder of the drag operation should be ignored.
c) (if impossible): if a slider does respond to a drag, that same drag should not also cause the screen to scroll as it does right now.
With these changes it would be possible to scroll a list of sliders without having to worry about accidental value changes.
toddparker commentedon Apr 20, 2012
For a, there are a lot fo non-touch mobile platforms (WP7, WebOS) so the only way to use the slider is to tap the track or use the input, sliding the handle won't work so this would make these platforms break.
We can look at b and c, but since this is a feature request, we're going to close this until we schedule this. Mind linking this issue from the feature request wiki page?
gknops commentedon Apr 20, 2012
I envisioned a as an option, possibly enabled via a class similar to ui-hidden-accessible and others. As requested I linked this issue to the feature request page.