CSS Only Styled Range Slider — Vendor Pseudo-Elements, No JavaScript

The native <input type="range"> is genuinely useful — real keyboard support (Arrow keys, Page Up/Down, Home/End), real form submission, real accessibility semantics — but its default appearance is inconsistent and hard to theme across browsers. This snippet keeps the native element and its behavior intact, and restyles only its rendering, using the vendor-prefixed pseudo-elements each browser engine exposes for exactly this purpose.

Why appearance: none is the starting point

-webkit-appearance: none (and the standard appearance: none) strips the browser's default slider chrome entirely, leaving a bare, unstyled <input>. Without this reset, none of the pseudo-element rules below reliably override the native rendering, because the default UI is drawn by the browser's own theme engine rather than styleable elements in the normal cascade.

Two separate pseudo-element vocabularies

There is no single standard set of pseudo-elements for range input parts — each engine defines its own, and this snippet targets both by necessity. WebKit browsers (Chrome, Safari, Edge) expose ::-webkit-slider-runnable-track for the groove and ::-webkit-slider-thumb for the draggable handle. Firefox exposes ::-moz-range-track for the groove, ::-moz-range-thumb for the handle, and — usefully — ::-moz-range-progress, a pseudo-element WebKit has no equivalent for for that automatically fills from the track's start up to the current thumb position.

How the colored fill-track effect is achieved differently per engine

In Firefox, ::-moz-range-progress does the filled-portion rendering for free — the browser handles clipping it to the current value. WebKit has no such pseudo-element, so the filled effect there is faked with a linear-gradient hard-stop on ::-webkit-slider-runnable-track: a CSS custom property --fill marks the percentage where the gradient switches from the accent color to the track's neutral gray. Because this snippet uses no JavaScript, --fill is set as a static fallback value per slider (matching each value attribute's initial position) rather than updating live as the thumb moves — which is the honest limitation explained below.

The honest tradeoff: no live-updating fill or value label

This is a real, worth-stating limitation: raw CSS has no way to read a range input's current numeric value and feed it back into a content string or a custom property as the user drags the thumb. The attr() CSS function can only read *static* HTML attributes, not the live, JS-updated value property a range input holds while being dragged — and even the attribute (value="65" in the markup) never changes as the user interacts, since dragging updates the DOM property, not the HTML attribute. So the WebKit gradient fill's hard-stop percentage in this snippet reflects only the *initial* value baked into the CSS, not a continuously-accurate live position — the fill will look correct at rest but won't visually track the thumb while dragging in WebKit browsers. A live-updating fill or an on-screen numeric readout genuinely requires either JavaScript (listening for the input event and updating a CSS custom property or text node) or accepting Firefox's native ::-moz-range-progress behavior, which does update live natively in that one engine only.

Three variants, one mechanism

The Volume, Brightness, and Quality sliders reuse the identical pseudo-element structure with different colors, thumb shapes (circular vs. a rounded-square "chunky" thumb for Quality), and track heights — demonstrating that once the vendor pseudo-element pattern is in place, theming additional variants is a matter of overriding a handful of color and sizing values per class, not rebuilding the slider from scratch.

Where a native range input still wins over a JS-built slider

Even accepting the live-fill limitation, a native <input type="range"> keeps full keyboard operability, screen-reader announcement of the current value, and real form submission — all free from the browser — none of which a from-scratch JS/div-based slider gets without deliberately reimplementing it. And because it needs no JavaScript to render, drag, or submit its value, it continues to work in sanitized CMS content, email, and script-stripped embeds, where a div-based custom slider control could not function at all.