(this will be an explainer: "In the early phases of design, this may be as simple as a collection of goals and a sketch of one possible solution." see https://w3ctag.org/explainers/)

# Slider

## Motivation

The HTML 5 era introduced a new `<input type="range">`. As described on MDN

> [In order to] let the user specify a numeric value which must be no less than a given value, and no more than another given value. The precise value, however, is not considered important. This is typically represented using a slider or dial control rather than a text entry box like the number input type.

Slider and dial input controls (not to be confused with carousel sliders) are common in many UI toolkits, and often used in web interfaces. The use of the term "range" is fairly unique to HTML. In ARIA, 'range' is an abstract role shared by many more concrete controls - the one that relates to the control provided by `<input type="range">` is called "[slider](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/slider_role)" there too.

However, native `<input type="range">` controls are often not chosen by authors because of their shortcommings. According to HTTP Archive data, [about 1.7% of pages in mid-2022 include this control](https://chromestatus.com/metrics/feature/timeline/popularity/34). Conversely, the same dataset elements with `role=slider` [appear on 1% of pages](https://docs.google.com/spreadsheets/d/1ladaKh6RbtMKQwkccwxDJGQf85KyhfLrtlM_9e9sLH8/edit#gid=283521996), and we know that at least as many exist which are not accessible. In other words, at least half the time authors would turn to a slider, they will recreate the entire control rather than use the native one.

There are potentially several reasons for this, but a critical one is the difficultly in styling them for lack of common anatomy.

## Anatomy
Making things standard needs to start with the Shadow DOM structure. Otherwise, getting consistent results cross-browser is going to become more difficult, not easier.

Here's the structure I came to the conclusion would be best for a simple, single thumb slider (we can discuss multiple handles later as I've also dealt with that - detailed in this two part article I wrote for CSS-Tricks: one and two):

### Structure


// TODO: This list will have to get filled in more like the one in the link above
* a track part
* 2 progress parts, like IE/ pre-Chromium Edge had ::-ms-fill-lower and ::-ms-fill-upper; like in the IE/ old Edge these need to be nested inside the track, with one end attached to the corresponding end of the content-box of the track and the other end attached to the middle of the thumb (this is not how ::-moz-range-progress works and that's a big problem because it means that, as it is, this Firefox pseudo is... pretty much unusable)
* a thumb part that's a sibling of the track (not a child as it is the case in WebKit browsers) or doesn't have its motion restricted by the track or by the actual range input the way it's currently happening; this thumb and the track should be middle aligned vertically (currently not the case in WebKit browsers)

## Goals
- uniform and flexible styling characteristics
- ability to make use of `<label>` and `<output>` with the `for` attribute for similar a11y characteristics
- ability to attach a `<datalist>` like `<input type="range">`
- Form participation
- An answer for multiple thumbs (multi-range)

## Work in progress / interesting problems
- datalist can be used for values, for/output can be used for the 'value' - perhaps we can use popup api to allow for that to be a value that 'floats' to the right or above the slider, etc... But we still have to update the value and if it is above the slider/thumb. https://codepen.io/thebabydino/pen/YPEqVY sets custom properties on change and then all of that is plain CSS - would we want to introduce something like env variables which contained current values which could be used for positioning and in generated content like that?