Open Bug 841942 Opened 10 years ago Updated 2 months ago

Consider displaying tick marks for <input type=range> when @list/<datalist> is used


(Core :: Layout: Form Controls, enhancement, P3)





(Reporter: jwatt, Unassigned)


(Blocks 1 open bug)


(Keywords: access, dev-doc-needed, Whiteboard: [access-s4])


(1 file)

We should figure out what we want to do for @list support for <input type=range>, if anything.
Blocks: 841950
Blocks: 344618
Everyone should feel free to comment on what we should be doing for @list/<datalist> with <input type=range> and how much content authors would care about having this bug fixed relative to other things we could be doing. Also please do CC anyone you think might have an opinion.

I don't think fixing this should block us shipping <input type=range>. (To my mind it would be better to have this as an enhancement at some later date, assuming it's even worth working on this rather than other things on our list of high priority work.) If anyone disagrees, please do speak up.
My concern is that there is no way to feature-detect this for a specific type. Except that, I agree it iss more a nice to have than a must have. I think we should at least have a look and see how hard implementing this would be.
What does "implementing this" involve? What is the desired behavior in your opinion?
(In reply to Jonathan Watt [:jwatt] from comment #3)
> What does "implementing this" involve? What is the desired behavior in your
> opinion?

Would say that the minimum is:
- showing a tick for each valid values in the associated datalist;

Maybe there could be:
- have a "magnet effect" when the user is around those values;
- show the values (the numbers in the UI).

I would be perfectly fine with simply the ticks being shown.
This sounds like it could get very involved.

* We'd need UI design for each individual native theming backend,
  and -moz-appearance:none, for major and minor ticks, and rendering
  of the data point labels.

* We'd (presumably) need to provide some sort of pseudo elements for
  long and short ticks, yet those elements wouldn't really be
  reflowed and rendered themselves, but rather would have to be used
  as templates for repeating, somehow.

* We'd need to decide what should happen when some of the data points
  in the list are too close together for the available space. We'd
  need logic to measure tick metrics for the various themes and for
  unthemed styled pseudo elements, detect when this is the case and
  act "appropriately", whatever that means.

* Laying out and painting data point labels at the various ticks
  would make the above even more complex given they would add to
  the metrics, layout and fitting issue.

* We'd have to take transforms into account when figuring out when
  ticks and labels are "too close" to visually make sense, and
  acting on that.

* If we have a "magnet effect", how does that interact with @step
  and the clamp-to-values that @step introduces, especially when
  the @step and @list data points conflict?

* Throw vertical vs horizontal range into the mix for even more

* A range with ticks [and labels] is going to take up quite a bit
  of space - what are the layout rules for positioning and alignment
  of the whole thing, and how does that fit into the flow of a page?

Those are just the issues I can think of off the top of my head. Even without including labels in the UI, this sounds like it could take quite a lot of time to hash out the details for, and then another significant chunk of time to implement.

It's worth mentioning that none of the other browsers seem to do anything with datalist for type=range (probably because of the complexities listed above, or maybe because sliders with ticks look ugly).

I've also not seen anyone asking for this when I was researching type=range before starting this project FWIW.
Lack of feature-detection does not strike me as a major problem. Others shipped this without <datalist> support too. And not having that support degrades gracefully.
Ok, you win :)
No longer blocks: 841950
Blocks: 853822
No longer blocks: 344618
Severity: normal → enhancement
Summary: Figure out what we want to do for @list support for <input type=range> → Consider displaying tick marks for <input type=range> when @list/<datalist> is used
Duplicate of this bug: 1222762
Happy 2017 all!

Speaking from the perspective of creating data visualizations - a basic slider with tick marks would really enhance the usability of the range <input>.  In the interim years since this bug came up, looks like gecko/webkit as well as ie/edge show tick marks in this use case.

In my view, tick marks don't need to be major/minor -- simply rendering a tick mark for every <option> in the <datalist> would be tremendously helpful and consistent with other browsers.
Currently, HTML range inputs are not very useful because of the lack of any kind of gradiation. I think it's pretty rare that these tick marks aren't a beneficial feature; indeed, having at least some tick marks which are also labeled is a big help. Although type "range" is meant to be used when precision isn't important, realistically, there are times when users are going to be trying to achieve something resembling a specific value. Such as trying to hit 50% volume so that your track is the same volume as the others. Or aiming for about 60% transparency when adjusting an rgba color using a set of sliders in a graphic editor. You might get sort of in the area, but knowing you're on the dot for key or common values is a big help.

Anyway -- the real reason I'm commenting: I've set dev-doc-needed on this bug since if it's ever fixed, docs will need updating to note that Firefox supports it.
Keywords: dev-doc-needed
I haven't seen this mentioned, but Chrome supports this now. I don't know for how long.
Priority: -- → P3
Edge/Chrome/Safari all support this now.  I'm moving this to Layout since
I suspect it's primarily Layout work to implement this.
Component: DOM: Core & HTML → Layout: Form Controls
Attached file Testcase #1
No UA seems to support labels yet though.  (The URL I mentioned earlier
uses a polyfill so it's misleading for testing support for this feature.)

(In reply to Mats Palmgren (:mats) from comment #14)

No UA seems to support labels yet though. (The URL I mentioned earlier
uses a polyfill so it's misleading for testing support for this feature.)

MDN suggests Chrome 66 supports labels if the datalist is styled:

Version 66 (66.0.3359.181) of Chrome supports labels but the <datalist> tag has to be styled with CSS as its display property is set to none by default, hiding the labels.

This impacts accessibility because it's much easier to ensure good a11y if authors use native widgets. The longer we don't support things like this, the more custom (and probably inaccessible) implementations will proliferate.

Note that if/when the layout part of this is implemented, we'll need code in the a11y module to support this as well.

Related Twitter thread:

Keywords: access
Whiteboard: [access-p3]

Updating the Accessibility Team's impact assessment to conform with the new triage guidelines. See for descriptions of these whiteboard flags.

Whiteboard: [access-p3] → [access-s4]

Any updates on this? As a developer this is pretty frustrating, since I have to build a long workaround just to get this to work similarly on Firefox

You need to log in before you can comment on or make changes to this bug.