About half a year ago I wrote about the idea to have multi-handle range sliders as a native HTML element. I asked for feedback, and the community delivered. The proposal has moved forward since then, but it needs more voices to get browser vendors on board. Here's what happened, what changed, and what you can do. This article shows some of the survey results, and is a big call for help.
If you’ve been following along, you might remember that I wrote about multi-handle range sliders back in October 2025. I shared the Open UI explainer and asked for feedback. People actually responded, the article got shared, and the feedback form started filling up. That was encouraging.
A lot has happened since then. The proposal moved forward, some concerns got addressed, and I need your help again.
The proof-of-concept got an update
Quick thing first: the proof-of-concept web component got an update. I added examples on how this would look as a native HTML element from a coding perspective. Go have a look and let me know what you think.
Standing on shoulders
I wasn’t the first one to push for this idea… Ana Tudor wrote about multi-thumb sliders on CSS-Tricks back in 2020, building on earlier work by Lea Verou who actually had multi-range sliders as part of a spec at some point (they were sadly removed). Ana also contributed to the CSSWG discussion on standardizing range input styling, which has been important for aligning pseudo-element namings in recent specs, but also for me to read on what people want. Probably not delivering on all those things yet, but it’s a good starting point (I have to believe that).
She’s still engaged with the topic too. When I shared the proof-of-concept, she suggested using <output> instead of <div> for the tooltip values, which is a fair point, but I still need to look into that (sorry).
I also want to give a spacial thanks to Chris and Dave for mentioning the idea on the Shop Talk Show podcast.
The community spoke
After my first article, I shared a feedback form to collect thoughts from developers. I got 25 responses. Even if that number might not sound minblowing, the feedback itself was detailed and honest. I’m keeping everyone anonymous here, but really, if you’re reading this, thank you!
Numbers and concerns!
About 80% rated a native <rangegroup> component as a 4 or 5 out of 5, with over 60% going straight for the highest score. And over 80% had built or used a multi-handle slider in a project before, about half from scratch, the rest with a JavaScript library.
The problems people ran into were pretty consistent:
- Accessibility: “Getting accessibility right (I likely didn’t)”, one person wrote. Another called it “a complete nightmare getting the state management to just work in all contexts. And this was only for two thumbs.”
- Styling: Cross-browser styling inconsistency. If you’ve ever tried to style a native range input, you know.
- State management: Changing min and max dynamically, preventing overlapping thumbs, handling form submission.
- Touch devices: Making it actually work well on mobile.
When asked about benefits of a native solution, the top answers were: accessibility, standardization, ease of styling, reduced bundle size, and performance.
Some quotes that stuck with me:
“Multihandle ranges feel like something that should just exist in HTML, I don’t need to build them.”
And:
“Less JavaScript and more HTML for common UI patterns.”
The progressive enhancement strategy (browsers without support just show separate labeled range inputs) was well received too. Several people called it one of the most exciting aspects, but at the same time, the use cases where the fallback would work might be limiting to basic usages. (as in: you can run wild with this idea of the API, you might need a polyfil at some point for the more advanced ideas)
Concerns raised, and what changed
The feedback wasn’t all positive, and that’s a good thing. A few concerns stood out.
The disabled state
One respondent wrote:
“Don’t forget discussing the
disabledattribute. Would that make sense for one handle to be disabled and others not? In case of fallback to individualinput, woulddisabledpropagate to all the members? Or maybe an entirerangegroupcould be disabled but when it gets re-enabled, individual handles have their own disabled state?”
Good question. This is now fully addressed in the updated explainer. The disabled attribute on <rangegroup> follows the <fieldset> propagation model:
- Group-level disabling: Set
disabledon<rangegroup>and the whole thing goes non-interactive. All thumbs removed from tab order, no pointer events, excluded from form submission. - Individual thumb disabling: You can set
disabledon a single<input type="range">within the group. That thumb locks in place while others remain interactive. - State persistence: If you disable the group and re-enable it, individual thumbs that were disabled before keep their disabled state.
Accessibility
Accessibility was the most mentioned concern, rightfully so and even though I know a lot on the matter, I have very big expectations on what an accessibility expert is, and I’m not one of them. What’s been resolved:
- Keyboard navigation: Each thumb is a tab stop. Arrow keys work as expected. Page Up/Down, Home, and End work as you’d expect from a native range input.
- Screen reader announcements: When entering the group, the overall min, max, and stepbetween are announced. Each individual thumb then announces its own context.
- Validation at boundaries: When
stepbetweenprevents further movement, that needs to be communicated clearly. Still being refined.
Browser adoption
The most common concern was browser adoption. “How long before browsers ship this?” “How much polyfilling will we need?” To be honest, I don’t have a timeline. And that is precisely why this article exists, I wish I could bring better news, but I guess this is a marathon, not a sprint.
More than two thumbs?
When asked about three or more handles, most people initially said: “Nope, just min/max.” That is fair… But when they thought about it a bit more, some real use cases came up:
- Opening hours with gaps: A restaurant that closes between lunch and dinner needs four handles (AM open, AM close, PM open, PM close).
- SLA monitoring: Setting “target”, “warning”, and “critical” thresholds on a monitoring tool. Three handles on one track.
- Budget allocation: Splitting expenses across categories, each as a segment on a single slider.
- Calendar availability: Booking interfaces with multiple available time windows and gaps between them.
- Data visualization: Setting bin sizes across a histogram.
- Gradient generator: Everybody wants a freaking gradient generator 😅
The thing is, people don’t ask for what they’ve never seen. When talking to people, a lot of them told me they’d never considered more than two thumbs because no library they’d used supported it. It’s an unknown pattern. But when I showed the opening hours example or the budget allocator, the reaction was usually: “Oh, I didn’t think of that, but yeah, that makes sense.”
So the question isn’t really “do we need more than two thumbs?” It’s: but what if we could?
I know there isn’t massive traction for 3+ thumb use cases right now. I’m not going to pretend there is. But limiting the API to exactly two thumbs because we haven’t collectively imagined the alternatives yet feels like the wrong call. The <rangegroup> approach doesn’t impose a limit on purpose. It’s up to you to decide what makes sense for your use case.
Where things stand, and why I need you
The proposal has been actively discussed in Open UI telecons. Several decisions have been resolved, but do note that these might still change, it is early days:
- Handle count: No limit on the number of range inputs in a
<rangegroup>. Author responsibility. (For now, if community wants it) - Keyboard navigation: Each thumb gets a tab stop, standard range input keyboard behavior.
- Disabled attribute propagation: Fully specced, including individual thumb disabling and state persistence.
- Screen reader announcements: Layered model, group context first then individual thumb context.
- Naming conventions: All pseudo-elements follow the
slider-prefix from the CSS Forms specification.
But Open UI is (rightfully) asking for more developer feedback. This will also be needed before browser vendors commit engineering resources. I’ve been working on this for quite some time now, and I can’t move it further on my own. I’m not a browser engineer or affiliated with any big tech agency.
If you think multi-handle range sliders should be part of HTML, now is the time to say so.
- Share the explainer on socials. Tag browser vendors. Write about your use cases.
- Open an issue on the Open UI repo. Developer feedback on GitHub carries weight.
- Try the proof-of-concept. Break things. Tell me what doesn’t work.
- Write about your frustrations. Blog posts, social threads, anything.
As one respondent put it:
“We basically try to redesign multi-thumb sliders because of their poor performance and accessibility, and high implementation cost. Having a native, standardized method would be great.”
We’re all solving the same problem individually. A native solution would fix that for everyone.
Every now and then someone shares a post like this one from Ana Rodrigues, and it reminds me why this matters:
Thank you
Thank you to everyone who filled out the feedback form, to people who did the prior work, Dave and Chris for mantioning it on the show, and to the Open UI folks for taking this seriously.
I’ll keep asking the stupid questions. Some parts will definitely be out of my knowledge, but I’ll do my best to get it right and push for this thing to become a reality.
But I can’t do it alone. I need your help.
