This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10988 - add slider element
Summary: add slider element
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 enhancement
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2010-10-07 07:54 UTC by Jim Michaels
Modified: 2011-08-04 05:04 UTC (History)
10 users (show)

See Also:


Attachments

Description Jim Michaels 2010-10-07 07:54:51 UTC
something that would add wonderful (and needed) interactivity would be vertical slider and horizontal slider HTML controls as one element "slider" with an attribute of "orientation" or "layout" (whatever works best and fits with the existing spec). (Isn't layout being used in css3?)  since css doesn't mesh with html spec, shouldn't be a problem.

this element does not need to have flow content, I think it should be a singleton element, but it's up to you how you want to spec that part.  If you want a close tag, go ahead.

it should have a value attribute which should be read/write.  if you set the value attribute, it should change the position of the slider.  if you set a wrong value, it should select the next or previous closest position.

any slider is essentially limited by the resolution of the screen.  you can't get any more resolution to the slider than the resolution of the screen.  so you can specify the height and width in px. anything else wouldn't make sense. you could do it, but it would be up to the user to handle the slider calculations. 

this element(s) should be accompanied by an actual slider control in the user agent.

if the author calculates wrong, I suppose the control should either use the last value submitted (if the value attribute is even there) or (I think) should give the string "" which is not a number and should easily indicate an error, whichever you feel is more appropriate.  

I was thinking that server-side scripting and javascript can easily be coded to handle this kind of "" error with an if statement in a function to handle .

tic marks always start from zero if they are present.

attributes:
-----------
height=length
width=length
layout=vertical|horizontal  (defaults to horizontal)
value=integer|real
min=integer|real
max=integer|real
steps=integer|real
ticmajorstep=integer|real
ticminorstep=integer|real
and the usual global attributes.
Comment 1 Maciej Stachowiak 2010-10-07 08:02:13 UTC
HTML5 already includes a slider control - <input type=range>. (Or at least, the most likely default rendering is as a slider).
Comment 2 Jim Michaels 2010-10-07 09:04:30 UTC
Having the tick marks would be a nice visual touch, and would show where the steps are. People expect to see that in a slider.

I propose a choice between 1 of 3 following additional attributes to the input element:

A boolean called ticmarks.  this would simply turn on tic marks at all the steps. 


OR

ticmajorstep=realNumber (some sort of number)
ticminorstep=realNumber (some sort of number)

OR

ticmajorstep=realNumber (some sort of number)
ticstep=realNumber (some sort of number)


The html author can decide whether they are too "fine" (too close together) and either simply tuen off the boolean or reduce the resolution of the ticmarks by a power of 2, like 1/2 or 1/4, etc. for visual effectiveness.  and the author knows what they want as far as tic resolution.
Comment 3 Benjamin Hawkes-Lewis 2010-10-07 11:52:38 UTC
(In reply to comment #2)
> Having the tick marks would be a nice visual touch, and would show where the
> steps are. People expect to see that in a slider.
> 
> I propose a choice between 1 of 3 following additional attributes to the input
> element

I suggest you propose these visual styling properties as additions to CSS not HTML.
Comment 4 Jim Michaels 2010-10-09 10:55:49 UTC
frankly, I wouldn't eve know how to submit the bug.  maybe you can either do it for me, or change the product and component on this bug, and change the title to "add slider CSS properties".

if you can't, then tell me what to change the listboxes to.
Comment 5 Shelley Powers 2010-10-09 13:19:01 UTC
(In reply to comment #4)
> frankly, I wouldn't eve know how to submit the bug.  maybe you can either do it
> for me, or change the product and component on this bug, and change the title
> to "add slider CSS properties".
> 
> if you can't, then tell me what to change the listboxes to.

How the control is rendered is optional, but adding tick marks isn't really a CSS thing, either.

What you're asking for is a way of recording an increment for the range. That's information that isn't necessarily specific to the rendering. It could show that the value in the range increments by 5, rather than 1, based on whatever rendering. 

So, your bug and request are valid, and carefully documented. It still needs to be addressed by the HTML5 editor. Once he addresses it, then based on what happens, you can pursue the issue further, if need be.
Comment 6 Benjamin Hawkes-Lewis 2010-10-09 13:46:11 UTC
(In reply to comment #4)
> frankly, I wouldn't eve know how to submit the bug.

CSS WG doesn't use the bug tracker as far as I know, but you can submit feature proposals to the public mailing list:

http://lists.w3.org/Archives/Public/www-style/

(In reply to comment #5)
> What you're asking for is a way of recording an increment for the range. That's
> information that isn't necessarily specific to the rendering. It could show
> that the value in the range increments by 5, rather than 1, based on whatever
> rendering.

That's already covered by the "step" attribute:

http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-step-attribute
Comment 7 Shelley Powers 2010-10-09 14:25:34 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > frankly, I wouldn't eve know how to submit the bug.
> 
> CSS WG doesn't use the bug tracker as far as I know, but you can submit feature
> proposals to the public mailing list:
> 
> http://lists.w3.org/Archives/Public/www-style/
> 
> (In reply to comment #5)
> > What you're asking for is a way of recording an increment for the range. That's
> > information that isn't necessarily specific to the rendering. It could show
> > that the value in the range increments by 5, rather than 1, based on whatever
> > rendering.
> 
> That's already covered by the "step" attribute:
> 
> http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-step-attribute

Well, yes and no. It can control the actual incremental data values, but doesn't show an indicator value, regardless of how that indicator is rendered. 

For instance, if the range increments by 1, which is the default, but you want indicators at values of 5, this is additional information that cannot be captured in CSS, because it's related to data, not rendering. 

In fact, some JS libraries already allow, or are working on allowing, the developers to apply labels to these tick mark indicators.  This, again, could be additional information--and information that is not appropriate to CSS. How the different items are actually styled (color, width, font, etc) may be specific to CSS, but not the values, themselves.
Comment 8 Benjamin Hawkes-Lewis 2010-10-09 16:41:06 UTC
(In reply to comment #7)
> For instance, if the range increments by 1, which is the default, but you want
> indicators at values of 5, this is additional information that cannot be
> captured in CSS, because it's related to data, not rendering. 

Actually you can already do that with the "list" attribute. See the example at:

http://dev.w3.org/html5/spec/number-state.html#range-state

> In fact, some JS libraries already allow, or are working on allowing, the
> developers to apply labels to these tick mark indicators.

And you could do that with the "list" attribute pointing to suggestions with the "label" attribute:

http://dev.w3.org/html5/spec/number-state.html#range-state

http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-list-attribute
Comment 9 Shelley Powers 2010-10-09 19:25:00 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > For instance, if the range increments by 1, which is the default, but you want
> > indicators at values of 5, this is additional information that cannot be
> > captured in CSS, because it's related to data, not rendering. 
> 
> Actually you can already do that with the "list" attribute. See the example at:
> 
> http://dev.w3.org/html5/spec/number-state.html#range-state
> 
> > In fact, some JS libraries already allow, or are working on allowing, the
> > developers to apply labels to these tick mark indicators.
> 
> And you could do that with the "list" attribute pointing to suggestions with
> the "label" attribute:
> 
> http://dev.w3.org/html5/spec/number-state.html#range-state
> 
> http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-list-attribute

That sounds like it could work, and matches what Jim needs. The suggested rendering for range does seem to say that the datalist options are synced to the movement of the slider thumbnail. 

However, the datalist options don't print out, as a rendered label. And there's nothing in the rendering that suggests this should happen. When I tested with latest Webkit and Opera, the slider showed, but not the tick marks, or the labels. And Opera, I believe, does support both range and datalist. Webkit looks partially there[1], and the intention does seem to be to add markers -- but labels? Hard to say.

There was also no indication of snapping to anything, must less a rendered text mark. Of course, neither browser would render a vertical slider, either.

And how would the tick marks/labels map from an accessibility perspective? Right now, all that's mapped is role, value, min, and max. 

Some of these things might be controllable by CSS, but not all. So, with the fact that almost every last aspect of range is an optional rendering, I'm not sure we can really say range does meet Jim's needs--not as it is currently described in the HTML5 spec. 

Do you think CSS can take up the slack for all of this?

[1] https://bugs.webkit.org/show_bug.cgi?id=27247
Comment 10 Shelley Powers 2010-10-09 19:42:54 UTC
Correction, Opera and Webkit do seem to have implemented the snap-to behavior. A little reluctantly on the part of Webkit, but it is there.
Comment 11 Shelley Powers 2010-10-09 19:46:10 UTC
Sorry, Opera and Webkit snap to the steps, not necessarily the datalist.
Comment 12 Jim Michaels 2010-10-10 01:12:47 UTC
somehow datalist doesn't sound appropriate. I am talking about <input type="range" ... />

this would be a visual feature in addition to "snap-to".  it could potentially either
- put tic marks on the snap to steps
OR
- put tic marks in (either a finer and/or coarser than the snap-to, actually independent of the snap-to).  If the user makes a mistake, the snapto-grid won't match up with the tic marks.  but in this case you do have major and minor tic marks to go with your UI.



if snapping to steps is an issue, then there's the boolean attribute I outlined.



A boolean called ticmarks.  this would simply turn on tic marks at all the
steps. in CSS this could be called 
input-range-ticmarks:[none];
input-range-ticmarks:display;


OR

ticmajorstep=realNumber (some sort of number)
ticminorstep=realNumber (some sort of number)
this could be implemented in CSS as 
input-range-ticmarks-majorstep:[none];
input-range-ticmarks-majorstep:num;
input-range-ticmarks-minorstep:[none];
input-range-ticmarks-minorstep:num;


OR

ticmajorstep=realNumber (some sort of number)
ticstep=realNumber (some sort of number)
this could be implemented in CSS as 
input-range-ticmarks-majorstep:[none];
input-range-ticmarks-majorstep:num;
input-range-ticmarks:[none];
input-range-ticmarks:num;


I know nothing about how datalist should be displayed.
Comment 13 Jim Michaels 2010-10-10 02:06:47 UTC
now I get it.  a datalist, related to the list attrib of the input element, related to input type=range.  got it.  but it's still hard to see how the list attrib has anything to do with the tic marks.

currently the display of ticmarks is left up to the option of the browser.
I would like to make tic marks the option of the author.
Comment 14 Jim Michaels 2010-10-10 02:36:29 UTC
"In fact, some JS libraries already allow, or are working on allowing, the
developers to apply labels to these tick mark indicators.  This, again, could
be additional information--and information that is not appropriate to CSS. How
the different items are actually styled (color, width, font, etc) may be
specific to CSS, but not the values, themselves."


that's cool.  I don't necessarily want to have to rely on javascript to do that (linux boxen don't often enable js), but that's nice to have.  I wonder if that's extjs...

wouldn't surprise me if they are using a canvas element to do the job.
Comment 15 Shelley Powers 2010-10-10 03:01:04 UTC
(In reply to comment #14)
> "In fact, some JS libraries already allow, or are working on allowing, the
> developers to apply labels to these tick mark indicators.  This, again, could
> be additional information--and information that is not appropriate to CSS. How
> the different items are actually styled (color, width, font, etc) may be
> specific to CSS, but not the values, themselves."
> 
> 
> that's cool.  I don't necessarily want to have to rely on javascript to do that
> (linux boxen don't often enable js), but that's nice to have.  I wonder if
> that's extjs...
> 
> wouldn't surprise me if they are using a canvas element to do the job.

The jQuery UI library is working on extending the base library to add both tick marks and labels. YUI has tick marks, as does dijit:

http://docs.dojocampus.org/dijit/form/Slider 

Just for fun and giggles, you can also check out an innovative slider based on the select element. It's accessible, too.

http://www.filamentgroup.com/lab/update_jquery_ui_slider_from_a_select_element_now_with_aria_support/
Comment 16 Jim Michaels 2010-10-10 05:33:29 UTC
I have one last thing I forgot to add (lost this feature in the translation):

layout=[horizontal-top]|horizontal-bottom|vertical-left|vertical-right 
horizontal-top being the default if layout not specified.
or, this may be shorted to
layout=vertical|[horizontal]  


and possibly an associated stylesheet property
input-range-layout:vertical|[horizontal];  default
or
input-range-layout:[horizontal-top]|horizontal-bottom|vertical-left|vertical-right;


I forgot to add this in.  the layout was an important feature.  as CSS3 invites
vertical layouts to text and other elements, <input type="range" .../> should
also have the possibility of a vertical layout.  whether that is done through
an existing css3 property (which I previously saw, don't know if it still
exists), or whether it is specified through attributes, I think this needs to
be done also.
Comment 17 Benjamin Hawkes-Lewis 2010-10-10 10:24:42 UTC
(In reply to comment #9)
> However, the datalist options don't print out, as a rendered label.
> 
> And there's nothing in the rendering that suggests this should happen.

"The user agent may use the suggestion's label to identify the suggestion if appropriate."

http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-list-attribute

> And how would the tick marks/labels map from an accessibility perspective?
> Right now, all that's mapped is role, value, min, and max.

I don't see any concept of tick marks in ARIA.

The proposed Note mapping HTML5 semantics to native accessibility APIs should cover the mapping of native sliders, including option labels.

http://dev.w3.org/html5/html-api-map/overview.html

Submitted to the editors of that draft as Bug 11003.

(In reply to comment #13)
> currently the display of ticmarks is left up to the option of the
> browser.
> I would like to make tic marks the option of the author.

HTML5 defines conformance requirements for what semantics a user agent can extract from what bytes, not what user interface it chooses to place on top of those semantics.

I believe that's the correct approach, personally, but feel free to challenge it. I recommend doing so on a mailing list or a dedicated bug rather than in a narrow bug like this, since it would be a significant and deeply controversial shift of approach.

I'd hope it would be uncontroversial for the spec to include an example of a suggestion list with labels being used with input type="range", however.

I've opened a request for such an example as Bug 11004.

(In reply to comment #16)
> whether that [orientation] is done through
> an existing css3 property (which I previously saw, don't know if it still
> exists), or whether it is specified through attributes, I think this
> needs to be done also.

Orientation should be specified with CSS. Please submit such feedback to CSS WG, rather than in a bug on the HTML spec.

Note that WebKit have already added CSS for making native-look sliders horizontal or vertical:

http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/css/property/-webkit-appearance
Comment 18 Shelley Powers 2010-10-10 15:06:21 UTC
(In reply to comment #17)
> (In reply to comment #9)
> > However, the datalist options don't print out, as a rendered label.
> > 
> > And there's nothing in the rendering that suggests this should happen.
> 
> "The user agent may use the suggestion's label to identify the suggestion if
> appropriate."
> 
> http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-list-attribute
> 
> > And how would the tick marks/labels map from an accessibility perspective?
> > Right now, all that's mapped is role, value, min, and max.
> 
> I don't see any concept of tick marks in ARIA.

Hopefully an accessibility expert will correct me if I'm wrong, by tick marks themselves are a visual aid. The actual value should be read out for screen readers. 

Labels, though, are a different story. I'm assuming if a specific value in the range is given a label, it is the label that should be spoken, not the value. 

Currently, though, I don't see that there is a true mapping between the values given in the list/datalist and the actual range value.

> 
> The proposed Note mapping HTML5 semantics to native accessibility APIs should
> cover the mapping of native sliders, including option labels.
> 
> http://dev.w3.org/html5/html-api-map/overview.html
> 

Well, yes and no. It maps out the input type of range without the associated list/datalist. And the reference to the datalist in the mapping document is specific to something selectable, and that strikes me is not the equivalent behavior in this specific use case.


> Submitted to the editors of that draft as Bug 11003.
> 
> (In reply to comment #13)
> > currently the display of ticmarks is left up to the option of the
> > browser.
> > I would like to make tic marks the option of the author.
> 
> HTML5 defines conformance requirements for what semantics a user agent can
> extract from what bytes, not what user interface it chooses to place on top of
> those semantics.
> 
> I believe that's the correct approach, personally, but feel free to challenge
> it. I recommend doing so on a mailing list or a dedicated bug rather than in a
> narrow bug like this, since it would be a significant and deeply controversial
> shift of approach.
> 
> I'd hope it would be uncontroversial for the spec to include an example of a
> suggestion list with labels being used with input type="range", however.
> 
> I've opened a request for such an example as Bug 11004.
> 

Yes, noticed that. Thank you.

> (In reply to comment #16)
> > whether that [orientation] is done through
> > an existing css3 property (which I previously saw, don't know if it still
> > exists), or whether it is specified through attributes, I think this
> > needs to be done also.
> 
> Orientation should be specified with CSS. Please submit such feedback to CSS
> WG, rather than in a bug on the HTML spec.
>

I do agree that orientation should be CSS. Actual rendering of tick marks could also be CSS. 
 
> Note that WebKit have already added CSS for making native-look sliders
> horizontal or vertical:
> 
> http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html#//apple_ref/css/property/-webkit-appearance
Comment 19 Benjamin Hawkes-Lewis 2010-10-10 15:57:53 UTC
(In reply to comment #18)
> > I don't see any concept of tick marks in ARIA.
> 
> Hopefully an accessibility expert will correct me if I'm wrong, by tick marks
> themselves are a visual aid. The actual value should be read out for screen
> readers. 

To be clearer: I mean I don't see any obvious ARIA mapping for suggested labels for a range control.

> Labels, though, are a different story. I'm assuming if a specific value in the
> range is given a label, it is the label that should be spoken, not the value. 

Maybe. I'd be happy to expose both bits of information and let UAs (including AT) expose them to the user as they feel is most appropriate.

> Currently, though, I don't see that there is a true mapping between the values
> given in the list/datalist and the actual range value.

The value of the option element in the list is always an actual range value.

> > The proposed Note mapping HTML5 semantics to native accessibility APIs should
> > cover the mapping of native sliders, including option labels.
> > 
> > http://dev.w3.org/html5/html-api-map/overview.html
> > 
> 
> Well, yes and no. It maps out the input type of range without the associated
> list/datalist. And the reference to the datalist in the mapping document is
> specific to something selectable, and that strikes me is not the equivalent
> behavior in this specific use case.

Sorry, I mean "should" as in: this information *should* be included, but it is not yet.
Comment 20 Shelley Powers 2010-10-10 16:34:02 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > > I don't see any concept of tick marks in ARIA.
> > 
> > Hopefully an accessibility expert will correct me if I'm wrong, by tick marks
> > themselves are a visual aid. The actual value should be read out for screen
> > readers. 
> 
> To be clearer: I mean I don't see any obvious ARIA mapping for suggested labels
> for a range control.
> 

I believe the one example that I linked does demonstrate a possible ARIA mapping, but it is dependent on user agents to make the mapping between position of range indicator and associated option label. 

> > Labels, though, are a different story. I'm assuming if a specific value in the
> > range is given a label, it is the label that should be spoken, not the value. 
> 
> Maybe. I'd be happy to expose both bits of information and let UAs (including
> AT) expose them to the user as they feel is most appropriate.
> 
> > Currently, though, I don't see that there is a true mapping between the values
> > given in the list/datalist and the actual range value.
> 
> The value of the option element in the list is always an actual range value.
>

What needs to be clarified is what is available via API when the range indicator is at a specific position. 
 
> > > The proposed Note mapping HTML5 semantics to native accessibility APIs should
> > > cover the mapping of native sliders, including option labels.
> > > 
> > > http://dev.w3.org/html5/html-api-map/overview.html
> > > 
> > 
> > Well, yes and no. It maps out the input type of range without the associated
> > list/datalist. And the reference to the datalist in the mapping document is
> > specific to something selectable, and that strikes me is not the equivalent
> > behavior in this specific use case.
> 
> Sorry, I mean "should" as in: this information *should* be included, but it is
> not yet.

That's the purpose of filing bugs -- filling in the gaps.
Comment 21 Ian 'Hixie' Hickson 2010-10-12 10:25:36 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: no spec change
Rationale: As others have mentioned, <input type=range> with step="", list="", <datalist>, and CSS, are the current proposal to address this.

It's possible that we'll have to add more features in the future, but before doing so we should see how well the current feature is received by Web authors.
Comment 22 Jim Michaels 2010-10-15 10:51:00 UTC
the datalist's option element could have by default a minor tickmark, and a major ticmark could be a boolean attribute "majorticmark".

that is one possibility that could be added to <option ...>
Comment 23 Maciej Stachowiak 2010-10-15 20:21:25 UTC
(In reply to comment #22)
> the datalist's option element could have by default a minor tickmark, and a
> major ticmark could be a boolean attribute "majorticmark".
> 
> that is one possibility that could be added to <option ...>

This bug was originally a request to add a slider control, and it seems like that request has been satisfied. If there are further requests (such as to add particular features like tick mark support, then please file separate bugs for those.
Comment 24 Jim Michaels 2010-10-22 04:17:25 UTC
well, based on that suggestion I guess I am going to have to request that this bug be closed and I move most of my stuff from here under a new bug title.  I will try to report back what the bug number is, if I can still add comments.
Comment 25 Jim Michaels 2010-10-22 18:49:12 UTC
ok here it is, 
Bug 11127 - tic marks for <input type="range">
Comment 26 Michael Cooper 2010-10-26 15:34:55 UTC
Bug triage sub-team does not think this is a A11Y TF priority.
Comment 27 Jim Michaels 2010-10-26 21:56:46 UTC
I wouldn't mind if this bug was closed.  but I am not sure if I should be the one to close it, now that it has been assigned.
Comment 28 Shelley Powers 2010-10-26 22:50:48 UTC
(In reply to comment #27)
> I wouldn't mind if this bug was closed.  but I am not sure if I should be the
> one to close it, now that it has been assigned.

Sure, you opened it, you can close it.
Comment 29 Jim Michaels 2010-10-26 23:09:13 UTC
changed bug to resolved, worksforme.
Comment 30 Michael[tm] Smith 2011-08-04 05:04:30 UTC
mass-moved component to LC1