This is about more than range group but pops up a lot in feedback sessions I have on range sliders.
Authors frequently need a range control where the thumb's position along the track maps non-linearly to its value, most commonly a logarithmic or exponential scale. Today, this is impossible with <input type="range"> and is not covered by the Enhanced Range Input / <rangegroup> proposal. I'd like to discuss whether (and how) the enhanced range proposal should support custom value scales.
Problem
Native <input type="range"> is strictly linear: the value is always min + position × (max − min).
Classic example: a price filter from 1 to 1,000,000. With a linear scale, the entire 1–500,000 region (where most users actually shop) lives in the left half, and a 1px drag near the middle jumps by thousands, so fine-tuning a value like 20 or 40 is impossible. The same problem shows up for:
- Audio / signal controls (frequency, gain in dB)
- Zoom levels and map scale
- File / data sizes (KB → TB)
- Scientific inputs spanning many orders of magnitude
The long-standing workaround is a "log-linear" hack: drive a linear 0–100 slider and transform it in JS with Math.pow/Math.log, writing the real value to a hidden input. This loses the declarative model, complicates accessibility (aria-valuetext, announcements), and has to be re-implemented by every author.
I also found these examples:
https://stackoverflow.com/questions/37814574/exponential-growth-of-input-range-values
https://stackoverflow.com/questions/49814503/change-html-slider-step-exponentially
Proposed directions (for discussion)
Declarative keyword e.g. scale="logarithmic" (default linear) on the range input / . Covers the overwhelmingly common case with zero JS and degrades to a linear native control. The question is then how to adjust the scaling itself.
JS escape hatch, a bidirectional function pair (valueToPosition / positionToValue) for arbitrary scales (exponential, custom easing, piecewise). The declarative keyword would just be a built-in instance of this.
Conformance / progressive enhancement
In a non-supporting browser, scale would be ignored, and the control falls back to a linear native range. functional in some way, just without the non-linear feel. That keeps the progressive-enhancement story consistent with the rest of the proposal.
This is about more than range group but pops up a lot in feedback sessions I have on range sliders.
Authors frequently need a range control where the thumb's position along the track maps non-linearly to its value, most commonly a logarithmic or exponential scale. Today, this is impossible with
<input type="range">and is not covered by the Enhanced Range Input /<rangegroup>proposal. I'd like to discuss whether (and how) the enhanced range proposal should support custom value scales.Problem
Native
<input type="range">is strictly linear: the value is always min + position × (max − min).Classic example: a price filter from 1 to 1,000,000. With a linear scale, the entire 1–500,000 region (where most users actually shop) lives in the left half, and a 1px drag near the middle jumps by thousands, so fine-tuning a value like 20 or 40 is impossible. The same problem shows up for:
The long-standing workaround is a "log-linear" hack: drive a linear 0–100 slider and transform it in JS with Math.pow/Math.log, writing the real value to a hidden input. This loses the declarative model, complicates accessibility (aria-valuetext, announcements), and has to be re-implemented by every author.
I also found these examples:
https://stackoverflow.com/questions/37814574/exponential-growth-of-input-range-values
https://stackoverflow.com/questions/49814503/change-html-slider-step-exponentially
Proposed directions (for discussion)
Declarative keyword e.g. scale="logarithmic" (default linear) on the range input / . Covers the overwhelmingly common case with zero JS and degrades to a linear native control. The question is then how to adjust the scaling itself.
JS escape hatch, a bidirectional function pair (valueToPosition / positionToValue) for arbitrary scales (exponential, custom easing, piecewise). The declarative keyword would just be a built-in instance of this.
Conformance / progressive enhancement
In a non-supporting browser, scale would be ignored, and the control falls back to a linear native range. functional in some way, just without the non-linear feel. That keeps the progressive-enhancement story consistent with the rest of the proposal.