This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
HTML5 already includes a slider control - <input type=range>. (Or at least, the most likely default rendering is as a slider).
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.
(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.
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.
(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.
(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
(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.
(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
(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
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.
Sorry, Opera and Webkit snap to the steps, not necessarily the datalist.
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.
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.
"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.
(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/
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.
(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
(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
(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.
(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.
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.
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 ...>
(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.
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.
ok here it is, Bug 11127 - tic marks for <input type="range">
Bug triage sub-team does not think this is a A11Y TF priority.
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.
(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.
changed bug to resolved, worksforme.
mass-moved component to LC1