DaisyUI has a range component, but it doesn’t support dual-handle (min/max) sliders.
That becomes a limitation when building things like price filters, faceted search, dashboards, or admin tools.
This isn’t solvable with native HTML or CSS alone. A proper min/max slider requires JavaScript for multiple thumbs, value constraints, keyboard and touch interaction, and accessibility.
Once you accept that JS is required, there’s another issue:
there’s no obvious, DaisyUI-friendly solution.
What typically happens is:
- a slider library is introduced (often noUiSlider)
- its generated DOM is inspected
- styles are overridden to match DaisyUI
- that setup gets copied into the next project
- slightly differently each time
I’ve done this more than once. It works, but it’s repetitive and not very reusable.
The idea
Instead of repeating that wiring, I packaged it once:
- uses noUiSlider for behavior
- uses DaisyUI CSS variables for styling
- keeps styles scoped (no global overrides)
It’s essentially a small integration layer between the two.
What it provides
- dual-handle slider by default
- theme-aware via DaisyUI tokens (primary, accent, error, etc.)
- visual parity with DaisyUI range inputs
- automatic adaptation when the theme changes
Why a wrapper?
You can wire this up manually if you want.
The wrapper exists because:
- the choice of slider library isn’t obvious
- the DaisyUI ↔ noUiSlider integration is non-trivial
- the same setup tends to be re-implemented across projects
- Packaging the pattern once reduces that duplication.
Scope
This is intentionally small.
It’s not a DaisyUI core component, a Tailwind plugin, or a framework abstraction, just a focused utility for a missing use case.
If you run into this problem while using DaisyUI, this is one option to consider.
Top comments (0)