type: widget
release: 1.5
status: in planning
documentation: http://docs.jquery.com/UI/Slider
demo: http://jqueryui.com/demos/slider
1 - Description:
A slider allows a user choose from a continuous range of allowable values presented in a visual continuum. The simplest slider (G1) allows for a single point to be selected. A range of values can be selected by providing two sliders (G2) or having a combination of a slider with a fixed maximum (G3) or minimum (G4) value. Each of these slider types can also be presented hortzintally (G1-4) or vertically (G5). These should be able to be embedded into a page (G1-5, G8) or inserted into menus as small UI 'helpers' for form inputs or embedded controls (G6-7).
In the standard ThemeRoller slider, there is unfilled "track", one or two square sliders and a filled line that connects multiple sliders. We should provide a means to use the slider with a custom background image (G8).
Sliders should be able to be created by progressive enhancement techniques by scraping the values from a set of radio buttons, select options, unordered list or other html structures. The html > data utility will be instrumental for this. For a detailed example of a PE slider with axis labels and tooltip features, see Filament Group's example:
http://www.filamentgroup.com/lab/progressive_enhancement_convert_select_box_to_accessible_jquery_ui_slider/
Configuration options should include:
- horizontal/vertical orientation
- slider size (h,w) - determined via css
- number of sliders (1,2,3+?)
- array of specific values or min/max/increment (ex. 500-25,000 with increments of 25)
- x axis labels: auto show as many as you can fit or accept an increment (every 3 ticks) plus show min/mid/max labels
- x axis grouping labels
- tooltip of current value never/always/onDrag
There is an existing jQuery UI slider but it only supports horizontal sliders. PE support, axis labels and groupings, drag tooltips and other important features need to be added.
http://docs.jquery.com/UI/Slider
2 - Visual Design:

3 - Functional Specifications/Requirements:
Options/Methods/Callbacks
One handle slider (default)
- options:
- animate (boolean, default: false)
[Todd] Is this used to animate the handle to the next step for keyboard input or to move the handle to the next availble step when the stops event is fired from a mouse event?
[Richard] This is used to animate every time the handle moves except when the user is moving it by dragging with the mouse.
- max (float, default: 100)
- min (float, default: 0)
- orientation ('horizontal', 'vertical', 'detect', default: 'detect')
- range (true, 'max', 'min', default: false)
- step (float, default: 1)
- value (float, default: 0)
- values (array or floats, default: null)
- methods:
- callbacks:
- start (events: mousedown, keydown)
- slide (events: drag, key held down)
- stop (events: mouseup, keyup)
- change (events: mouseup, keyup, click, value option/method)
Specifications
- max, min, step, value should be get/set as integers/floats
- min must be less than max
- horizontal slider - min is at left, max is at right
- vertical slider - min is at bottom, max is at top
- value will always change by an increment of step, whether by keyboard or mouse
- keydown HOME on handle sets value to min
- keydown END on handle sets value to max
- keydown UP on handle increases value by step, not greater than max
- keydown RIGHT on handle increases value by step, not greater than max
- keydown DOWN on handle decreases value by step, not less than min
- keydown LEFT on handle decreases value by step, not less than min
- in the case of one handle, the slider min/max are min/max for the handle
- in the case of two handles, and range true, each handle's min/max is set by the current value of other handle. The first handle's min is the slider min. The last handle's max is the slider max
- if there are more than two handles, or range is false, the slider min/max are min/max for each handle
- range: true only works with two handles
- range: 'min' and range: 'max' only work with one handle
- value option/method: the value option is not restricted by min/max/step. What is returned by the value method is restricted by min (>=), max (<=), and step (even multiple)
- start callback: triggers when movement starts via mouse(mousedown) or keyboard(keydown). Not triggered by value option/method
- slide callback: triggers during movement via mouse(drag/mousemove) or keyboard(key held down). Not triggered by value option/method
- stop callback: triggers when movement stops via mouse(mouseup) or keyboard(keyup). Not triggered by value option/method
- change callback: triggers when the slider has stopped moving and has a new value (even if same as previous value), via mouse(mouseup) or keyboard(keyup) or value method/option
- mouse click (mousedown and mouseup without mousemove) triggers start, stop, change, but not slide
Changes from 1.5, 1.6rc2 in refactor
- 'axis' option was changed to 'orientation'
- 'handle' option removed
- 'handles' option removed
- 'steps'/'stepping' options removed in favor of 'step' option
if you want 5 evenly divided pieces, specify
min: 0, max: 5, step: 1
or
min: 0, max: 100, step: 20
-
'startValue' and 'moveTo' removed in favor of 'value' option and 'value' method
-
'round' option removed
-
'distance' option removed
-
'noKeyboard' option removed
-
multiple axis removed - too complex for 1.6, and doesn't make sense considering our upcoming full refactor of slider. May need to be a separate plugin
4 - Markup & Style:
4.1 Initial markup examples
(Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )
4.2 Recommended transformed HTML markup demo with html and css (live view of svn):
View Demo Page: http://jquery-ui.googlecode.com/svn/trunk/tests/static/slider.html
4.3 Markup & style browser QA status
As of 12/12/08, static markup for this widget renders correctly in the following browsers. (Correct rendering = true to design, with only small differences across browsers owing to differences in support of rounded corners, and native OS form element and font rendering.)
Please update this list as more browsers / platforms are tested.
|
|
XP
|
Vista
|
Mac 10.5
|
Linux (Debian) |
|
IE 6
|
|
|
|
|
|
IE 7
|
|
|
|
|
|
IE 8 beta
|
|
|
|
|
|
Firefox 2.0.0.18
|
|
|
|
|
|
Firefox 3.0.4
|
|
|
|
|
|
Safari 3.2
|
|
|
|
|
|
Opera 9.1
|
|
|
|
|
|
Opera 9.62
|
|
|
|
|
|
Chrome 1.0
|
|
|
|
|
| Epiphany-Webkit |
|
|
|
|
4.4 Accessibility recommendation
See keyboard support discussion.
The slider requires the following ARIA attributes:
- role="slider"
- aria-valuenow="<numeric value>"
- aria-valuemin="<minimum value of the slider's range>"
- aria-valuemax="<maximum value of the slider's range>"
- Optional: aria-valuetext="<text version of the slider's value>", such as "20 dollar" or "100 MB"
For range sliders, one handle provides a boundary for the other handle (as range sliders handles can't pass each other). Because of this, changes to the first handle (representing the lower value of the range) need to trigger an update to the "aria-valuemin" value of the second handle (representing the upper value of the range. Similarly, changes to the second handle need to trigger an update to the "aria-valuemax" value of the first handle.
Each handle needs to have an accessible name. This name can be set using either:
- A "title" attribute on the actual handle.
- An "aria-label" attribtue on the handle (not supported by IE8).
- An "aria-labelledby" attribute on the handle, referencing the ID of an element containing the label text.
- A separate <label> element with a "for" attribute referencing the ID of the slider handler.
Note that only the last option is really useful for sighted keyboard users. For the other options, redundant visual text will have to be added for a sighted user to understand what the handle represents.
Regardless of how the accessible name is implemented, the developer needs to be able to specify it through widget parameters.
4.5 CSS & Theme
(Description of the CSS classes to be used for all states, how custom theming and Themeroller support will work.)
5 - Latest version of plugin:
http://jqueryui.com/demos/slider
6 - Open issues being discussed
I'd like to bring attention to the sliders because in their current form they don't support any labeling or feedback which can be a big usability problem. I've copied these items from the description above to see if I can get answers on whether we think we can get these features into the cleanup for 1.6rc3:
Example of a working version with these feature here on the Filament group site:
http://www.filamentgroup.com/lab/progressive_enhancement_convert_select_box_to_accessible_jquery_ui_slider/
How should multiple handles' min/max/value be get/set after init?
- [Richard] One option would be to grab each handle using a jQuery selector (using id, class, filter, index, :first, :last, :eq) and call .slider() on it (not init, just for options, methods), so you can access the handle's individual min, max, value using the same options/methods as the slider. This is quite a big change in terms of the jQuery UI API. Any other ideas?
Comments (22)
RichCaloggero said
at 2:14 pm on Jan 13, 2009
This doesn't work at all.
On the "default" demo page, all I see is one object that is announced as a
link by the screen reader and has "#" as its anchor text. Clicking on it
does nothing.
I tried both Jaws (my default screen reader), and the open source NVDA
screen reader which boasts good ARIA support. Find their site at:
http://www.nvda-project.org/
Maybe jQuery-ui project aught to coloborate with these folks directly. If we
could get this stuff working in just one screen reader, then ARIA would have
a better chance getting the press / recognition it needs to succeed.
-- Rich
RichCaloggero said
at 2:29 pm on Jan 13, 2009
I just tried a simple test:
with a dummy slider control: just a div with role="slider".
For giggles, I included a button made from a span with an alert as onclick, and a heading made from a span with aria-level=2. Jaws correctly announced the heading and level, and it announced the button correctly and responded to the click by focusing on the alert dialog when it came up. When the dummy slider gains focus, Jaws announces it as a "trackbar".
This suggests that perhaps the aria on the slider page is not correct or missing?
-----
<body>
<h1>Roles</h1>
<div role="heading" aria-level="2">Role Tests</div>
<p>Here are some objects:<br/>
<span tabindex=0 role="button" onclick="alert('yikes'); return false">Click Me</span><br/>
<span tabindex=0 role="slider">Slide Me</span><br/>
</p>
</body>
-----
-- Rich
Marc Grabanski said
at 12:33 pm on Jan 30, 2009
I think the ui slider should default to horizontal. Currently the auto-detect orientation seems strange and bugged my current site when I upgraded. Why would I want UI to tell me what orientation my slider is going to be based of factors unknown to me?
Scott González said
at 7:41 pm on Feb 16, 2009
Slider should be updated to be more consistent with HTML 5 input ranges (http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#range-state)
hugh.lomas said
at 9:17 pm on Jul 2, 2009
Hey, I was working on an application for Facebook and adapted the slider to:
Accept only pre-determined non-linear intervals (i.e. 5,10,20,50,100, 500). This can be edited dynamically.
Provide visual feedback with tick-marks of valid values and min/max, and an output of the current value above it
You can view an example on the second screen of
http://apps.facebook.com/giftparty/hostparty.php
hugh.lomas said
at 9:19 pm on Jul 2, 2009
p.s. My edits may have some quirks, would probably need cleanup, but the idea is there and functional.
Yanick said
at 5:13 am on Jul 3, 2009
Having a transformation function is not necessarily useful in this context as the slider itselft does not display a tooltip of the currently selected value (or any textual representation of such value). Therefore, an implementation is superfluous. To achieve the same principle, any textual visual representation can pass through such transformation function when the "change" event gets fired. An example would be :
$(".selector").slider({ min:0, max:6, change: updateVisual});
var values = [5,10,20,50,100,500];
function updateVisual(e, ui) {
$(".label").text( values[ui.value]);
};
The last example virtually achives the exact same result without even touching the plugin source.
Yanick said
at 5:35 am on Jul 3, 2009
Or yet this one:
// only change the values in this array to modify the non linear values
var nonlinearValues = [5,10,20,50,100,500];
$(".selector").slider({
min:0,
max:nonlinearValues.length-1,
change: function updateVisual(e, ui) {
$(".label").text(nonlinearValues[ui.value]);
}});;
or a sigmoid function (-10 to 10 with 4 floating point precision, for example):
$(".selector").slider({
min: -10,
max: 10,
change: function updateVisual(e, ui) {
var precision = 10000;
var val = Math.round( (1/( 1 + Math.pow(Math.E,(-1*ui.value)))) * precision) / precision;
$(".label").text( val );
}});;
GreyCells said
at 7:50 am on Jan 19, 2010
A fairly common use case relating to range sliders: When two handles are specified, the div.ui-slider-range between them should be draggable.- so the start/end handles can be moved as a pair.
Samir Rayani said
at 9:28 pm on Jan 31, 2010
Have you seen a good implementation for this? I've been looking around, but no luck
Jörn Zaefferer said
at 9:33 am on Mar 17, 2010
Whats the point of change being triggered when the value hasn't changed?
Richard D. Worth said
at 11:47 am on Mar 17, 2010
It makes implementation A LOT simpler and shouldn't have any negative consequences. It's a setter notification. If the value gets set the event triggers.
Scott González said
at 12:56 pm on Mar 17, 2010
But that breaks the model of what a change event is. There's a clear model from existing native events and we've been following that for our widgets.
Richard D. Worth said
at 1:28 pm on Mar 17, 2010
That's a good point.
Richard D. Worth said
at 2:11 pm on Mar 17, 2010
Interesting. The spec seems quite clear
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents
"The change event occurs when a control loses the input focus and its value has been modified since gaining focus. This event is valid for INPUT, SELECT, and TEXTAREA. element."
Despite that you'll find wildly different results across those 3-5 elements in our supported browsers http://jsbin.com/arita3 . That suggests (at least) to me that it's not unheard of for change to trigger even when the value hasn't changed.
Richard D. Worth said
at 12:22 pm on Mar 17, 2010
It also makes the event model a lot simpler. [START], [SLIDE... [SLIDE ... ]], [STOP], CHANGE. It's a lot simpler to say it's always triggered after STOP and it's always triggered than to say it will trigger if the value is the same after STOP as it was before START. The slider could've had a lot of interim (not actually set) values during the SLIDE phase. A final event is needed to ensure things can be cleaned up and consistent. STOP isn't fitting because it only makes sense for STOP to trigger is START triggered, which isn't the case for programmatic sets. So this means the CHANGE event can be used equally well in the mouse, keyboard, and programmatic settings.
Jörn Zaefferer said
at 2:47 pm on Mar 20, 2010
Other widgets with a animation-option call it "animated", Slider has "animate". I vote for deprecating "animate" and replace it with "animated".
Ralph Whitbeck said
at 3:27 pm on Mar 20, 2010
When I saw this in my e-mail I saw "animated" and thought that would be right for a boolean value.
Coming here and seeing that it is planned to be I also vote for "animated"
By deprecating it though would we just not document it that way and allow both animate and animated both set the same option? I don't think we can take it away without supporting it even if we don't document it.
Richard D. Worth said
at 3:49 pm on Mar 20, 2010
With 1.8 out now, the soonest we can deprecate something is 1.9. The soonest the same could be removed is 2.0
Ralph Whitbeck said
at 3:55 pm on Mar 20, 2010
That's not true you can change the documentation to the new way of doing things and start campaigning to use the new option. The old option still works but is not "supported" . A soft deprecation.
A hard deprecation would be a 1.9 or 1.10+ type of change.
Richard D. Worth said
at 3:33 pm on Mar 20, 2010
I think slider animate is more consistent with dialog show and dialog hide. Let's change accordion animated to animate to be consistent with these.
Ralph Whitbeck said
at 4:07 pm on Mar 20, 2010
I support this!
You don't have permission to comment on this page.