[range] Support non-linear (e.g. logarithmic) value scales

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.

Start by reading the Enhanced Range Input and proposal alongside this issue, then compare the declarative scale and JavaScript escape-hatch directions described here. Done means the project has a decided, specified approach for non-linear scales, including progressive enhancement and accessibility behavior.