Slider

Min, Max and Step set the scale and the distance between two values the user can land on - 0 to 10 stepping by 1 unless you say otherwise. Left unbound the slider keeps its own state, and DefaultValue only picks where that state starts. Disabled greys it out and takes it out of the tab order; ReadOnly keeps it at full contrast, focusable and announced, and refuses every change.

The thumb answers the pointer three ways: drag it, press the rail anywhere to send it there and carry straight on dragging, or step it with the keyboard. A value that arrives in one jump is eased into; a thumb held under the pointer follows it exactly and takes the accent's pressed shade while it does.

IsRanged gives the slider a second thumb, so it selects a span rather than a point - a price bracket, an age band, the hours a shift covers. The ends are LowerValue and UpperValue, each bindable on its own, with RangeValue carrying both at once and DefaultLowerValue / DefaultUpperValue as their unbound counterparts.

The rail is divided between the two thumbs at their midpoint: press it anywhere and the nearer thumb comes to meet you, then keeps following the pointer as if you had grabbed it. The keyboard reaches them as two tab stops in a fixed order. By default the thumbs may cross - Range constraints shows how to stop them.

ShowMarks draws a tick at every Step. MarkStep widens that interval for a scale too fine to mark at each one - a 0 to 1000 slider wants its marks every 100 - and ShowMarkLabels writes each tick's value underneath, formatted the way the value labels are. ShowMarkLabels asks for the marks on its own, so ShowMarks is only needed when nothing else has - while MarkStep only spaces the marks something else has asked for.

For anything beyond a regular series, hand Marks a list of BitSliderMark - a value, an optional label, its own class and style. That is how a scale gets named stops ("Low", "Medium", "High") instead of numbers, or one threshold gets painted red; a mark left without a label takes its own value while ShowMarkLabels is on. Marks the fill has reached are repainted so they stay legible on top of it, and marks outside Min..Max are skipped.

MarkLabelTemplate replaces the text under every mark with markup of your own, handed the mark it belongs to - a row of faces, an icon per tier, a value over a caption. It asks for the marks like the other two. They are decoration and hidden from screen readers either way, so a scale labelled only by pictures still needs AriaValueText to say what it is on.

RestrictToMarks makes the marks the only values the user can pick, which is what turns an irregular scale into something the pointer and the keyboard can both land on exactly. A drag lands on the mark nearest the pointer; an arrow key always reaches the next one along, however short a Step is against the gap between them. On a range a snapped move still stops at the outermost mark the constraints leave room for. It governs only what the user can pick - a value bound from elsewhere is always drawn where it actually is.

IsVertical stands the slider upright and fills it from the bottom up, so "more" is up - the direction ArrowUp already means. The marks, their labels and the floating thumb label follow, and the value labels stack instead of flanking. An upright slider has no length of its own to inherit, so it takes one from the --bit-Slider-length CSS variable, per instance or globally. Reach for it when the value is naturally a height - a level, a gain, a temperature.

The fill normally grows out of the near end, which reads as "how much". IsOriginFromZero anchors it to zero instead, so a negative value fills one way and a positive one the other, with a tick where zero actually sits - only the middle of the track on a scale symmetric around it, as the -2..8 example shows. Origin is the same idea with any anchor: a target, a baseline, last month's figure. Both are held inside Min..Max, and both are about the single value - a range already has two ends of its own to fill between.

Inverted moves the origin to the far end, so the fill shows what is left rather than what is used; an inverted range fills the two outer segments instead, which is how an excluded band is drawn. NoFill removes the bar altogether for a value with no sense of accumulation - a hue, a seek point - and with it the repainting of the marks the fill would have reached.

ThumbLabel puts the value on the thumb. Auto shows it only while the slider is hovered, dragged or focused; On keeps it there permanently. It follows both ends of a range and takes the same ValueFormat the other labels do. A horizontal slider holds the room the label rises into open above its track - --bit-Slider-thumb-label-room - so an Auto label appearing mid-drag never lands on the caption; an upright one puts the label beside the thumb, on the side the mark labels do not take. Pair it with ShowValue="false" to keep the row compact.

ThumbLabelTemplate replaces its content with markup of your own - an icon that changes with the level, a unit in its own type. It is handed the value that thumb stands for, so one template serves both ends of a range.

MinRange is the smallest distance the two thumbs may be apart, which keeps a range from collapsing onto a single value; MaxRange is the largest, so a thumb stretching the range past it stops there; NoSwap asks for the ordering alone. Any of the three also stops the thumbs crossing. A starting pair that does not satisfy them is widened or narrowed until it does and reported back to whatever the range is bound to, and limits that contradict each other resolve rather than lock up.

Pushable changes what happens when the thumbs meet: the moving one carries the other along instead of stopping against it, so a constrained range slides bodily across the scale from either end rather than a thumb at a time. The pushed thumb stops at the end of the scale and the pushing one rests beside it. It has nothing to do until there is a MinRange to keep or a NoSwap to hold.

All of them are enforced by the browser rather than corrected afterwards - the constraint is pushed into the bounds of the underlying input - so a thumb never moves somewhere it will be pulled back from, by pointer or by key, and that holds for a move snapped onto a mark too.

DraggableTrack makes the filled band a handle in its own right: press it and the whole range travels with the pointer, keeping the width it had - one gesture instead of dragging one end and then chasing it with the other. It comes to rest when its leading end reaches the end of the scale, or the outermost mark that still leaves room for its width, and since the thumbs never change their distance on the way, every range constraint holds throughout.

Only the rail strictly between the thumbs takes the drag, so the thumbs stay grabbable and a band squeezed below a thumb's width has nothing to take hold of - which is what keeps a range dragged shut from being impossible to open again. The trade is that a press on the band no longer sends the nearer thumb there.

It reports through OnRangeChange and OnRangeChangeEnd like any other move; set MinRange and MaxRange to the same number for a fixed-width window. It is a pointer gesture, so the keyboard still reaches the two ends one thumb at a time.

ValueFormat is an ordinary .NET numeric format string, applied to every label the slider draws - beside the track, under the marks and on the thumb - and rendered in the culture of the user. When the number is not what the value means, GetValueText builds each label from the value itself: minutes as "12:30", bytes as "1.5 MB", a step index as the word it stands for. ShowValue="false" drops the labels beside the track, and LabelTemplate replaces the plain Label with markup of your own.

The labels are set in tabular figures and hold open the width of the longest text the scale reads, so the track keeps its length as the value crosses from 9 to 10 instead of resizing under the thumb.

@bind-Value is the usual two-way binding. Handing Value over one-way instead makes the slider follow that value and refuse to change it on its own, for when something else owns the number - the first pair below is driven entirely by the rating beside it. A range has three bindings: @bind-LowerValue and @bind-UpperValue separately, or @bind-RangeValue for both at once. All three are kept in step, so a slider bound only by RangeValue still reports through LowerValueChanged.

OnChange fires on every step, which is what keeps a live preview in sync with the thumb. OnChangeEnd fires once, when the interaction ends, and that is where anything expensive belongs: a query, a save, a request. A range has the same pair as OnRangeChange and OnRangeChangeEnd, each handed a BitSliderRangeValue carrying both ends. Drag the sliders below and watch how much more often the first counter moves than the second.

OnFocusIn and OnFocusOut fire as a thumb takes and gives up the focus. A range reports through both from either thumb, so tabbing from one to the other fires an out and then an in.

Inside an EditForm the slider is a form field like any other: it joins the EditContext, reports every move to it, and repaints its track and thumb in the error color while the value is invalid. Since a slider always holds some number, the interesting annotation is usually a Range narrower than the scale itself allows. Required announces that expectation ahead of the failure instead of leaving the error message to be the first mention of it, and Name makes the value readable by a plain form post.

A range joins through @bind-RangeValue: the pair is one field of the model rather than two, so it carries its own annotation and repaints the moment the pair stops satisfying it. The second form below asks for a span of at least 20 - drag the thumbs together and the error comes back without waiting for another submit.

Every thumb is a real range input, so the whole slider keyboard is there without asking: the arrows move by a Step, PageUp / PageDown jump further, and Home / End go to the ends of the scale. A range is two tab stops in a fixed order, as the WAI-ARIA multi-thumb pattern prescribes, and each thumb announces the bounds it can actually reach - so a constrained range tells a screen reader user where the thumb beside it has stopped them. A read-only slider is the exception: its bounds refuse the change rather than describe the value, so it announces the whole scale.

LargeStep names how far those larger jumps go. Left alone they are whatever the browser makes of a Page key - every engine measures it differently and none makes anything of Shift - which is hopeless on a long scale. Setting it pins the Page keys to that distance and gives Shift with an arrow the same reach, leaving the rest of the keyboard as it was. A jump is held inside the same bounds every other move is, and lands on a mark while RestrictToMarks is on.

Label names the slider when nothing else does, AriaLabel overrides it, and LowerAriaLabel / UpperAriaLabel name the two ends of a range apart - without them a screen reader announces the same name twice and the user cannot tell which thumb they are on. Where the thumbs may cross, the names travel with the values, so the one announced as the minimum always holds it. A slider captioned only by a LabelTemplate points both thumbs at that caption instead. AriaValueText is what a thumb announces in place of its number - 2 as "Medium", 750 as "12:30" - and falls back to GetValueText when only the visible form is given. AutoFocus, FocusAsync and FocusUpperAsync place the focus, and the two inputs are there as SliderInputElement and UpperSliderInputElement.

AriaDescription carries what a name has no room for - a unit, a rule - into a hidden element every thumb points at through aria-describedby, so it is announced after the name and the value; an id you pointed the inputs at yourself, a validation message among them, is kept alongside it rather than replaced. A range is wrapped in a labelled group, as the multi-thumb pattern asks. Required is announced through aria-required and marked with the usual asterisk. The labels the slider draws - the value beside the track, the text under a mark - are left out of the accessibility tree, since the thumb beside them announces the same value and a reader given both would say every number twice. Each thumb's grab area is at least 24px across whatever size it is drawn at, meeting the minimum pointer target of WCAG 2.2, and a drag answers with the accent's pressed shade the way a keyboard focus answers with a ring.

BitParams carries a BitSliderParams down to every slider under it, so a panel, a form or a page sets the shared scale, marks and look once instead of on every slider. What it carries is a default and not an override: a slider that writes a parameter for itself keeps its own value and takes from the cascade only what it left unset.

Everything a group can share is on the params object - the scale and the step, the marks, the color and the size, the accessible names of the two ends of a range - together with the ReadOnly and Required every input inherits, which is what makes a whole section of a form read-only in one place. What each slider holds of its own is not: a value, a default value, a name, the templates and the event callbacks stay on the markup.

Color picks the theme color the fill and the thumbs are painted in, with Primary as the default; the rail stays neutral whichever is chosen, so it keeps reading as "not reached yet" rather than as a second, dimmer accent. The semantic colors tie the slider to what its value means, while the Background, Foreground and Border families keep it legible on non-default surfaces like the inverted panel below. Each brings its own hover, pressed and focus shades with it.

Size scales the track, the thumbs and the labels together, from the Small that fits a dense settings panel to the Large that carries the main control on a page; Medium is the default. Whichever it is, the grab area stays at least 24px across, so even a Small slider is usable with a finger.

Style and Class reach the root element. Styles and Classes go a level deeper and address the parts by name - Root, Label, Container, SliderBox, Track, Fill, Thumb (with LowerThumb and UpperThumb for the two ends of a range), the underlying inputs (ValueInput, LowerValueInput, UpperValueInput and the TrackInput a draggable band adds), Mark, MarkLabel, ThumbLabel, OriginFromZero and the value labels - so the fill can take a gradient, the thumbs a shape of their own, or the two ends of a range two different colors.

For what no parameter and no part covers, the slider reads a set of CSS variables off its root: the geometry of the thumb and the rail, every color of every state, the type of the labels, the room the mark labels and the floating one are given, and the look of that floating label. They inherit, so a value on :root or any ancestor re-skins every slider below it while one on Style re-skins that instance alone, and anything left unset falls back to the theme token beside it - which is how a reshaped slider still follows the Material or Cupertino preset.

Set once on an ancestor, inherited by every slider inside it:

Setting Dir to Rtl mirrors the whole slider: the scale starts on the right, the fill grows leftwards from it, the marks and their labels follow that edge, and ArrowLeft raises the value because that is the direction the scale now runs in. A vertical slider is deliberately left alone, since up means more in both directions of reading.