Open UI

Enhanced Range Input (Explainer)

Authors
@utilitybend
Created
Last Updated

Background

The <input type="range"> element has long been a part of HTML forms, providing a slider control for selecting numeric values. However, its current implementation lacks flexibility in styling and functionality, leading developers to often resort to custom implementations. These custom solutions can result in reduced performance, reliability, and accessibility compared to native form controls.

The web development community has expressed a need for more customizable and feature-rich range inputs, particularly for use cases such as price range selectors, date/time range pickers, and other multi-value selection scenarios.

Goals

  1. Standardize the anatomy and structure of range inputs across browsers.
  2. Provide a comprehensive styling API for range inputs.
  3. Introduce support for multi-handle range inputs through a new <rangegroup> element.
  4. Enhance accessibility for range inputs, especially for multi-handle scenarios.
  5. Improve the overall user experience and developer ergonomics for range inputs.

Current State of Range Styling

Currently, the state of styling <input type="range"> across browsers is inconsistent and challenging. Different browsers use their own pseudo-elements for styling range inputs, leading to a fragmented landscape for developers. Here’s an overview of the current state:

::-webkit-slider-thumb {
    /* Styles the thumb */
}
::-webkit-slider-runnable-track {
    /* Styles the track */
}

Firefox:

::-moz-range-thumb {
    /* Styles the thumb */
}
::-moz-range-track {
    /* Styles the track */
}
::-moz-range-progress {
    /* Styles the progress/fill below the thumb */
}

IE/Edge:

::-ms-thumb {
    /* Styles the thumb */
}
::-ms-track {
    /* Styles the track */
}
::-ms-fill-lower {
    /* Styles the progress/fill below the thumb */
}
::-ms-fill-upper {
    /* Styles the fill above the thumb */
}

This fragmentation makes it difficult for developers to create consistent range input styles across browsers, often requiring browser-specific code or fallbacks.

There currently is a running draft solution for this found at: https://www.w3.org/TR/css-forms-1/. We would at least like to maintain the same naming convention:

  • ::slider-track: The main track along which the thumb(s) move.
  • ::slider-fill: The filled portion of the track, typically between the minimum value and the thumb on single-handle range controls.
  • ::slider-thumb: The draggable handle for single range controls (or matching all handles when targeted on <rangegroup>).

Taking this further, we propose functional pseudo-elements and new pseudo-elements following the same convention:

  • ::slider-thumb(n) / ::slider-thumb(*): Selects specific handle(s) by index (1-indexed) or all handles when targeting a <rangegroup>.
  • ::slider-segment(n): Sections of the track between handles in multi-handle ranges (aligning with CSSWG discussions on multi-fill styling in w3c/csswg-drafts#12419).
  • ::slider-tick(*): Optional tick marks along the track for value representation (when paired with a <datalist>).
  • ::slider-tick-label: Labels associated with tick marks (when paired with a <datalist>).

This would follow the idea of the appearance: base value from the CSS Forms specification:

input[type="range"] {
    appearance: base;
}

This opt-in approach allows developers to access enhanced styling capabilities while maintaining a partial backwards compatibility.

Multi-Handle Support with <rangegroup>

Based on community feedback and discussions, we propose a new approach for multi-handle functionality. Instead of adding a new attribute to the existing <input type="range"> element or adding a new type, we believe a new <rangegroup> element could offer us the correct flexibility. This would be a wrapper element that can contain multiple <input type="range"> elements.

A live proof-of-concept demonstrating these ideas can be found at: https://brechtdr.github.io/enhanced-range-slider-poc/

This approach offers several advantages:

  • Easy feature detection
  • Better progressive enhancement as browsers that don’t support <rangegroup> will still display individual range inputs
  • Clearer separation of concerns between individual range handles
  • More intuitive form submission with distinct name/value pairs
  • Simplified styling and attribute management

Example usage:

<rangegroup>
    <legend>Temperature Range</legend>
    <label>
        Minimum Temperature
        <input type="range" name="temp-min" value="-25" />
    </label>
    <label>
        Maximum Temperature
        <input type="range" name="temp-max" value="15" />
    </label>
</rangegroup>

The <rangegroup> element would visually present these as a single slider with multiple handles on a common track, while maintaining the individual inputs for form submission and JavaScript interaction.

Accessibility Enhancements

To improve accessibility, especially for multi-handle ranges, the <rangegroup> element is designed to work with established HTML patterns for labeling and grouping form controls.

Individual thumbs must be focusable and operable via the keyboard. The <rangegroup> approach achieves this by using actual <input type="range"> elements for each handle, preserving their native accessibility features. Users can tab between handles, and each handle maintains its standard keyboard controls (e.g., arrow keys for adjustment).

Labeling

A robust labeling strategy is crucial for users of assistive technologies. We propose a pattern that mirrors the accessible and progressively enhanced structure of <fieldset> and <legend>.

Group Label: The <rangegroup> element should be labeled by including a <legend> element as a direct child. This provides the accessible name for the entire group of sliders.

Individual Handle Labels: Each <input type="range"> within the group should have its own accessible name. This can be provided by wrapping the <input> within a <label> element (implicit labeling), which is the recommended approach. Alternatively, standard methods like an aria-label or aria-labelledby attribute on the <input> can be used.

Example Implementation

<rangegroup>
    <legend>Price Range</legend>

    <label>
        Minimum Price
        <input type="range" name="price-min" value="25" />
    </label>

    <label>
        Maximum Price
        <input type="range" name="price-max" value="75" />
    </label>
</rangegroup>

Focus Behavior

This approach also defines clear focus behavior.

  • Clicking a <label> will focus its associated <input>’s handle, as is standard for form controls.
  • The <legend> element provides a group name but does not have a default click-to-focus behavior. This is appropriate, as there are multiple focusable targets within the group, avoiding ambiguity.

Keyboard Interaction

Each thumb within a <rangegroup> is a tab stop. Keyboard behavior for each thumb follows the existing conventions for <input type="range">:

  • Tab / Shift+Tab: Moves focus between thumbs (and in/out of the group).
  • Arrow Left / Arrow Down: Decreases the focused thumb’s value by one step.
  • Arrow Right / Arrow Up: Increases the focused thumb’s value by one step.
  • Page Down: Decreases the value by a larger step increment.
  • Page Up: Increases the value by a larger step increment.
  • Home: Sets the focused thumb to its minimum value.
  • End: Sets the focused thumb to its maximum value.

This preserves familiarity with native range input behavior. When a <datalist> is associated, arrow keys snap to the nearest datalist value rather than stepping by a fixed increment.

Screen Reader Announcements

When a user navigates into a <rangegroup> for the first time (focusing the first thumb), the group’s overall min, max, and stepbetween values should be announced. Each individual thumb then announces its own min, max, and current value. This layered announcement model ensures users of assistive technologies understand both the group context and the specific handle they are controlling.

Disabled State

The <rangegroup> element supports the disabled attribute, following the same propagation model as <fieldset>. This provides both group-level and individual-handle control over interactivity.

Group-Level Disabling

When the disabled attribute is set on the <rangegroup> element, the entire control becomes non-interactive. All thumbs are removed from the tab order, pointer interactions on the track and thumbs are ignored, and the contained inputs are excluded from form submission.

<rangegroup disabled>
    <legend>Price Range</legend>
    <label>
        Minimum Price
        <input type="range" name="price-min" value="200" />
    </label>
    <label>
        Maximum Price
        <input type="range" name="price-max" value="800" />
    </label>
</rangegroup>

The track and all thumbs should be rendered in a visually distinct disabled style (e.g., reduced opacity) to communicate the non-interactive state.

Individual Thumb Disabling

The disabled attribute can also be set on individual <input type="range"> elements within a <rangegroup>. A disabled thumb is locked at its current value, removed from the tab order, and cannot be moved by pointer or keyboard. Other thumbs in the group remain fully interactive.

<rangegroup>
    <legend>Price Range</legend>
    <label>
        Minimum Price (locked)
        <input type="range" name="price-min" value="200" disabled />
    </label>
    <label>
        Maximum Price
        <input type="range" name="price-max" value="800" />
    </label>
</rangegroup>

All Thumbs Disabled

When every <input type="range"> within a <rangegroup> has the disabled attribute, the group should behave as if the <rangegroup> itself were disabled. The track is painted in its disabled state and there are no tab stops within the group.

State Persistence

If a <rangegroup> is disabled and later re-enabled (by removing the disabled attribute), any child inputs that were individually disabled before the group was disabled retain their own disabled state. This matches the standard behavior of <fieldset> with its child form controls.

Progressive Enhancement

This behavior aligns well with progressive enhancement. In a non-supporting browser, setting disabled on individual <input type="range"> elements works as expected with standard HTML semantics. When <rangegroup> is supported, its disabled attribute provides the additional capability of disabling all handles at once.

Progressive Enhancement

The <rangegroup> approach is designed with progressive enhancement as a core principle. In browsers that do not support the element, the markup gracefully degrades to standard, functional HTML form controls.

For example, consider a price range selector:

<rangegroup>
    <legend>Price Range</legend>

    <label>
        Minimum Price
        <input type="range" name="price-min" value="100" min="0" max="1000" />
    </label>

    <label>
        Maximum Price
        <input type="range" name="price-max" value="750" min="0" max="1000" />
    </label>
</rangegroup>

In a supporting browser: This renders as a single slider track with two draggable handles, labeled “Minimum Price” and “Maximum Price”, under a group heading of “Price Range”.

In a non-supporting browser: This renders as two separate, standard <input type="range"> sliders. Each slider is correctly labeled, fully functional, and accessible. The <legend> will appear as plain text, still providing context for the group of inputs that follow. This ensures the form remains usable and understandable for all users, regardless of browser support, without requiring JavaScript polyfills for basic functionality.

Design Consideration: range vs. number inputs

A consideration was raised whether <input type="number"> might serve as a better base for progressive enhancement than multiple <input type="range"> elements. While <input type="number"> provides a valid fallback for setting a range, we believe using base <input type="range"> elements better preserves the design intent. A range input is designed for selecting an approximate value within a scale, where the user is more interested in the position along the track than a precise number. This aligns with the visual metaphor of the enhanced <rangegroup> component. Using <input type="range"> as the fallback provides a more equitable, if not identical, user experience.

Datalist Integration

We propose standardizing and enhancing the integration of <datalist> with range inputs and rangegroups. This will allow for consistent implementation of tick marks and predefined values across browsers. For <rangegroup> elements, the <datalist> can be associated with the group as a whole, and all contained range inputs will share the same tick marks:

<rangegroup name="price-range" min="0" max="100" list="price-ticks">
    <legend>Price Range</legend>
    <label>
        Minimum Price
        <input type="range" name="price-min" min="0" max="50" value="20" />
    </label>
    <label>
        Maximum Price
        <input type="range" name="price-max" min="50" max="100" value="80" />
    </label>
</rangegroup>
<datalist id="price-ticks">
    <option value="0">$0</option>
    <option value="25">$25</option>
    <option value="50">$50</option>
    <option value="75">$75</option>
    <option value="100">$100</option>
</datalist>

Alternatively, datalist could be provided on each input as well. While these won’t render inside of the <rangegroup>, they would render on individual inputs when there is no support for the feature.

Multi-Color Range Segments

To support different colors between handles in a <rangegroup>, we introduce the ::slider-segment(n) pseudo-element (aligning with CSSWG discussions on multiple slider fills in w3c/csswg-drafts#12419). This allows for granular control over the appearance of each segment in the range, enabling rich user interfaces such as budget allocators where each segment can represent a different category. Segments get numbered based on their start and end positions with 1 being at the start (based on writing mode). Example usage:

rangegroup::slider-segment(1) {
    background-color: #ff5733;
}

/* Style the second segment (between the first and second handles) */
rangegroup::slider-segment(2) {
    background-color: #33ff57;
}

/* Style the third segment (between the second handle and the end) */
rangegroup::slider-segment(3) {
    background-color: #3357ff;
}

The number of segments is determined by the number of thumbs.

Detailed Design

HTML Attributes

<rangegroup> Attributes

  • min: Specifies the minimum value for the entire range group, defining the lower bound of the track.
  • max: Specifies the maximum value for the entire range group, defining the upper bound of the track.
  • name: The name of the range group, used for identification.
  • list: Links the range group to a <datalist> element, providing tick marks or predefined values.
  • stepbetween: Defines the minimum distance between handles in a range group.
  • disabled: When present, disables the entire range group. All contained handles become non-interactive, are removed from the tab order, and their values are excluded from form submission. This mirrors the behavior of the disabled attribute on <fieldset>.

<input type="range"> Attributes (within a <rangegroup>)

These attributes function as they normally would, but their values are constrained by the parent <rangegroup>.

  • min: The minimum value for this specific handle. Its effective range is determined by its interaction with the parent <rangegroup>.
  • max: The maximum value for this specific handle. Its effective range is determined by its interaction with the parent <rangegroup>.
  • value: The current value of this handle. This still updates individually by changing the thumb.
  • name: The name of this specific range input for form submission.
  • step: The step increment for this specific handle. This results in the steps of the thumb in a rangegroup environment, meaning that each thumb could potentially have different steps.
  • disabled: Disables this specific handle. The thumb is locked at its current value, removed from the tab order, and excluded from pointer interactions. Other handles in the group remain interactive. When all child inputs are disabled, the group behaves as if it were disabled as a whole.

min and max Attribute Interaction

The <rangegroup> element and its child <input type="range"> elements can both have min and max attributes. Their interaction is key to providing both flexibility and a coherent progressive enhancement story.

  • <rangegroup> min and max: These attributes define the overall coordinate space of the slider. They determine the full visual range of the track.
  • <input> min and max: These attributes define the allowable value range for that specific handle.

The effective range for any given handle is the intersection of its own constraints and the parent <rangegroup>’s constraints. The tightest constraint always wins. In other words, a handle’s value must be greater than or equal to both its own min and the group’s min, and less than or equal to both its own max and the group’s max.

  1. If a handle’s range is within the group’s range (e.g., rangegroup max="100", input max="70"): The track will render from 0 to 100, but the handle will be prevented from moving past 70. This is a desirable pattern for use cases like a seek bar for a live video stream, where the total buffer is visible but the user cannot seek into the future.
  2. If a handle’s range exceeds the group’s range (e.g., rangegroup max="100", input max="200"): The handle’s movement will be clamped by the <rangegroup>’s bounds. The handle will not be able to exceed a value of 100. This ensures the component’s visual representation is the source of truth and prevents invalid states.

This model supports progressive enhancement. In a non-supporting browser, the individual inputs with their min and max attributes function correctly as standalone sliders. When <rangegroup> is supported, it unifies the UI and can apply overarching constraints without breaking the underlying inputs.

Track Click Behavior

To provide an intuitive single-pointer interaction model, the <rangegroup> component’s track-clicking behavior mirrors that of the native <input type="range">.

When a user clicks or taps anywhere on the slider’s track, the component identifies the thumb closest to the click location and moves it to that position.

This approach offers several benefits:

  • Familiarity: It aligns with user expectations based on the standard behavior of single-handle sliders and some popular component libraries.
  • Direct Manipulation: It provides a quick and direct way for users to move any handle to a desired point with a single click, without needing to drag.

Disabled thumbs are excluded from the closest-thumb calculation. If only one thumb is active and the other is disabled, a track click will always move the active thumb.

While this interaction is powerful, it’s worth noting that on touch devices with coarse pointers, care must be taken to avoid accidental adjustments. However, we believe the benefit of adhering to a well-established browser-native pattern provides the most valuable and predictable user experience.

Overlapping Thumbs

Because overlap is permitted (see Thumb collision handling), the pointer model needs a deterministic way to pick which thumb a drag should move when two or more thumbs currently share the same value. We propose the following resolution algorithm as the current behavior for a first prototype:

  1. On pointer-down over a position where multiple thumbs overlap, do not commit to a thumb immediately.
  2. Track pointer movement without moving any thumb until the pointer has moved past a small horizontal threshold (implementation-defined, e.g. a few pixels) from the pointer-down position.
  3. Once the threshold is crossed, use the movement direction to disambiguate: a move toward lower values activates the leftmost (start-most, writing-mode aware) of the overlapping thumbs; a move toward higher values activates the rightmost (end-most) thumb.
  4. That thumb remains active for the rest of the drag, following the same clamping rules (stepbetween, per-thumb min/max) as a normal drag.
  5. If the pointer is released before crossing the threshold, no value changes and no change fires — this is treated as a discrete activation/focus event on the topmost thumb rather than a move.

This keeps overlapping thumbs individually reachable by pointer without requiring authors to prevent overlap via stepbetween. The broader question of whether this is the right default (versus, for example, z-order stacking or a dedicated disambiguation UI) remains open — see Thumb collision handling.

CSS Properties and Pseudo-elements

To address the current fragmentation and provide a unified styling API, we propose the following pseudo-elements, aligning with the CSS Forms specification:

  • ::slider-track: Represents the main track of the range control or <rangegroup>.
  • ::slider-fill: Represents the filled portion of the track on a single <input type="range">.
  • ::slider-segment(n): Represents sections of the track between handles in a <rangegroup>.
  • ::slider-thumb: Represents the draggable handle on a single <input type="range">, or all handles when targeted on <rangegroup>.
  • ::slider-thumb(n) / ::slider-thumb(*): Represents specific draggable handle(s) within <rangegroup> by index (1-indexed) or wildcard matching.
  • ::slider-tick(*): Represents individual tick marks on the range group with an attached datalist.
  • ::slider-tick-label: Represents the label associated with each tick mark of a datalist option.

Example usage:

/* Styling a basic range input */
input[type="range"] {
    appearance: base;
}

input[type="range"]::slider-track {
    height: 4px;
    background-color: #ddd;
}

input[type="range"]::slider-fill {
    background-color: #4caf50;
}

input[type="range"]::slider-thumb {
    width: 20px;
    height: 20px;
    background-color: #2196f3;
    border-radius: 50%;
}

/* Styling a multi-handle rangegroup */
rangegroup {
    appearance: base;
}

rangegroup::slider-track {
    height: 6px;
    background-color: #f0f0f0;
}

rangegroup::slider-segment(1) {
    background-color: #ff5733;
}

rangegroup::slider-segment(2) {
    background-color: #33ff57;
}

/* Target all thumbs in the rangegroup */
rangegroup::slider-thumb(*) {
    width: 24px;
    height: 24px;
    background-color: #2196f3;
    border-radius: 50%;
}

Exposing Thumb and Segment Geometry to CSS

To support layout customization beyond a straight horizontal track, we propose exposing each thumb’s position along the track via a CSS function (such as control-value() from the CSS Forms specification or a specialized slider-position() function returning a <percentage> or <number>), rather than browser-injected CSS custom properties. Segments similarly expose their start position and size. This is purely additional information for styling — it does not change hit-testing, keyboard behavior, or value computation, which remain based on the linear min/max model described above.

Authors can combine this function with standard CSS features (such as offset-path and CSS anchor positioning) to lay thumbs out along a custom visual path — for example a curved or circular track — without any new HTML attributes or UA-required geometry. See the wavy-track and circular-track examples in the proof-of-concept for an illustration of this pattern:

rangegroup::slider-thumb(*) {
    offset-path: path("M0,40 Q40,15 80,40 T160,40 T240,40 T320,40");
    offset-distance: control-value();
}

JavaScript API

The existing JavaScript API for <input type="range"> remains unchanged inside of the group.

For groups specifically we’d like to introduce a few new ones:

  • values: A property that returns an array of values for all contained range inputs.
  • inputs: A property that returns a collection of the contained range input elements. A shorthand for querySelectorAll
  • getRangeInput(index): Returns the range input at the specified index.
  • setRangeValue(index, value): Sets the value for a specific handle.

Example usage:

const rangeGroup = document.querySelector('rangegroup[name="price-range"]');

// Getting values
console.log(rangeGroup.values); // [100, 750]

// Getting inputs
const inputs = rangeGroup.inputs;
console.log(inputs.length); // 2

// Setting a specific handle's value
rangeGroup.setRangeValue(0, 150);
console.log(rangeGroup.values); // [150, 750]

Extra Examples

Dual-Handle Range Group

<rangegroup name="price-range" min="0" max="1000">
    <legend>Price Range</legend>
    <label>
        Minimum Price
        <input type="range" name="price-min" min="0" max="500" value="250" step="10" />
    </label>
    <label>
        Maximum Price
        <input type="range" name="price-max" min="500" max="1000" value="750" step="10" />
    </label>
</rangegroup>

rangegroup {
    appearance: base;
    width: 300px;
}

rangegroup::slider-track {
    height: 6px;
    background-color: #f0f0f0;
}

rangegroup::slider-segment(1) {
    background-color: #ddd;
}

rangegroup::slider-segment(2) {
    background-color: #4caf50;
}

rangegroup::slider-segment(3) {
    background-color: #ddd;
}
rangegroup::slider-thumb(*) {
    width: 24px;
    height: 24px;
    background-color: #2196f3;
    border-radius: 50%;
}

Multi-Handle Range Group with Colored Segments

<rangegroup name="temperature-range" min="-100" max="100">
    <legend>Temperature Range</legend>
    <label>
        Low
        <input type="range" name="temp-low" min="-100" max="-25" value="-50" />
    </label>
    <label>
        Medium
        <input type="range" name="temp-medium" min="-25" max="25" value="0" />
    </label>
    <label>
        High
        <input type="range" name="temp-high" min="25" max="100" value="75" />
    </label>
</rangegroup>

rangegroup {
    appearance: base;
    width: 300px;
    height: 20px;
}

rangegroup::slider-track {
    height: 10px;
    background-color: #ddd;
}

rangegroup::slider-thumb(*) {
    width: 20px;
    height: 20px;
    background-color: #2196f3;
    border-radius: 50%;
}

rangegroup::slider-segment(1) {
    background-color: #ff5733;
}

rangegroup::slider-segment(2) {
    background-color: #33ff57;
}

rangegroup::slider-segment(3) {
    background-color: #3357ff;
}

rangegroup::slider-segment(4) {
    background-color: #ff33a8;
}

Resolved Decisions

The following reflect current Open UI telecon consensus and are the basis for a first browser prototype. Where a tracking issue remains open on GitHub for further refinement, that is noted explicitly — “resolved” here means “settled enough to prototype against,” not “closed.”

  • Handle count limits (#1337, tracking issue remains open): No limit is imposed on the number of range inputs in a <rangegroup>. It is the author’s responsibility to determine the appropriate number for their use case. Community feedback is being gathered on the prevalence of 3+ thumb use cases to determine whether a simpler two-thumb attribute API should coexist with the N-thumb <rangegroup> approach. See also #1183 for the related discussion on whether any maximum should be imposed.
  • Keyboard navigation (#1185, tracking issue remains open): Each thumb gets a tab stop. Arrow keys, Page Up/Down, Home, and End behave as they do on a standard <input type="range">. See the Keyboard Interaction section.
  • Disabled attribute propagation (#1338, tracking issue remains open): disabled on <rangegroup> cascades to all thumbs. Individual thumbs can be disabled independently. When all thumbs are disabled, the group behaves as fully disabled. See the Disabled State section.
  • Screen reader announcements: The group’s min, max, and stepbetween should be announced when entering the group (first thumb). Each thumb then announces its own min, max, and current value. See the Screen Reader Announcements section. Separately, how a screen reader should communicate a blocked move (e.g. a thumb constrained by stepbetween) is still open — see #1339 below.
  • Naming convention (#1197): All pseudo-elements use the slider- prefix (e.g., ::slider-track, ::slider-thumb), following the CSSWG decision in the CSS Forms specification.

Considerations and Open Questions

Filed under the Enhanced range slider label on the Open UI tracker. For a first native prototype, the items above under Resolved Decisions plus Overlapping Thumbs and Track Click Behavior are considered in scope; the items below are explicitly deferred pending further discussion.

  • Thumb collision handling (#1184): How should overlapping thumbs behave? Current consensus leans toward allowing overlap for the initial version, with the option to refine behavior based on real-world usage. Authors can prevent overlap using stepbetween or per-thumb min/max constraints. The Overlapping Thumbs section describes the pointer-disambiguation algorithm proposed for a first prototype; whether this is the right long-term default remains under discussion.
  • Track click behavior (#1278): The current proposal moves the closest thumb to the click position. Alternative approaches (e.g., only moving thumbs when clicking outside the selected range, or no track-click on touch devices) have been suggested and remain under discussion.
  • Handle count and maximum limitations (#1183): Should there be any UA-imposed maximum on the number of thumbs in a <rangegroup>, and if so, what are the accessibility implications of many handles versus two? See also #1337.
  • What is the label? (#1244): The Labeling section proposes <legend> for the group and <label>/aria-label/aria-labelledby per thumb. Open questions remain around how assistive technology should identify individual handles when authors use patterns other than wrapping <label> elements, and whether additional guidance or constraints are needed.
  • Standardizing feedback for constrained movement (#1339): When a thumb’s movement is blocked (e.g. by stepbetween or a neighboring thumb’s min/max), should there be standardized visual and/or assistive-technology feedback, similar to how some platforms indicate a control has reached a limit?
  • Linking input elements with a slider value (#1459): Should there be a declarative way to bidirectionally link a <rangegroup> thumb to another control (e.g. an <input type="number">) so that editing one updates the other, without authors writing JavaScript?
  • Segment dragging (#1460): Should authors (or the platform by default) be able to drag an entire segment, moving both of its bounding thumbs together while preserving their distance (e.g. an iOS-style alarm/sleep-schedule range picker)? This would likely be an opt-in JavaScript-driven pattern rather than default behavior; accessibility implications are unexplored.
  • Multiple simultaneous touch points (#1461): On touch devices, should it be possible to drag two thumbs at once with two fingers? The proof-of-concept does not currently support this.
  • Maximum distance between thumbs (#1462): stepbetween defines a minimum gap between adjacent thumbs. Should there also be a way to define a maximum gap (e.g. a maxstepbetween attribute)?
  • Per-pair stepbetween: (#1463): With three or more thumbs, should the minimum distance be configurable independently for each adjacent pair, rather than a single group-wide stepbetween value?
  • Non-linear value scales (#1464): Should range inputs and <rangegroup> support non-linear (e.g. logarithmic or exponential) mapping between thumb position and value, for cases like price or frequency ranges spanning several orders of magnitude? This is a larger question about <input type="range"> in general, not specific to multi-handle groups.
  • Vertical orientation: How should we handle vertical orientation for range inputs? The CSS Forms specification introduces a slider-orientation property that could be adopted for this purpose.
  • Automatic tick mark generation: Should we provide options for generating tick marks without requiring a <datalist> (e.g., evenly spaced ticks based on a step attribute on the rangegroup)?
  • Tick mark legibility: How can we ensure that tick marks and labels remain legible and usable on small-screen devices or with a large number of ticks? Is this author responsibility?
  • Programmatic segment styling: Should we provide a way to set segment colors via a JavaScript API?
  • Programmatic constraint violations: What should the behavior be when a handle’s value is updated programmatically to a value that would violate stepbetween or other range limits?
  • Form submission: How should form submission work for <rangegroup> elements? Each child <input> submits its own name/value pair individually, as standard form controls. Should the <rangegroup> also support a group-level submission format?