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

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
--
enhancement
5 years ago
4 months ago

People

(Reporter: jwatt, Unassigned)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

Trunk
dev-doc-needed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
We should figure out what we want to do for @list support for <input type=range>, if anything.
Blocks: 841950
Blocks: 344618
(Reporter)

Comment 1

5 years ago
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.
(Reporter)

Comment 3

5 years ago
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.
(Reporter)

Comment 5

5 years ago
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
  fun.

* 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.

Comment 6

5 years ago
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
(Reporter)

Updated

5 years ago
Blocks: 853822
(Reporter)

Updated

4 years ago
No longer blocks: 344618
(Reporter)

Updated

2 years ago
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
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1222762

Comment 9

6 months ago
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.
You need to log in before you can comment on or make changes to this bug.