Control Center Panel — Free HTML CSS JS Snippet

iOS Control Center is one of the most recognizable pieces of mobile UI in existence: a frosted-glass card of square toggle tiles for Wi-Fi, Bluetooth, Airplane Mode and Focus, sitting alongside vertical sliders for brightness and volume that fill from the bottom as you drag. None of that is achievable with native HTML form controls — a checkbox does not bounce or recolor on toggle, and <input type="range"> is permanently horizontal with no supported way to rotate it into a bottom-up vertical fill bar without breaking its hit-testing and accessibility semantics. This snippet rebuilds the whole panel from primitive <button> elements and raw Pointer Events, giving full control over the visual state machine and letting the entrance, toggle, and drag interactions all be tuned independently.

Toggle tiles: a data attribute as the single source of truth

Each tile is a plain <button> with a data-on="true" or data-on="false" attribute — that attribute is the entire state model, and CSS attribute selectors (.tile[data-on="true"]) handle all the visual differences: background color, icon color, and icon-well opacity. Clicking a tile simply flips the attribute string and lets CSS transitions animate the background-color and color changes over 220ms. Airplane Mode and Focus get their own override colors (orange and indigo) when active, matching how iOS visually distinguishes different toggle categories rather than using one blanket "on" color for everything.

The bounce: retriggering a CSS animation from JavaScript

A naive classList.add('bounce') on a class that is already present does nothing, because the browser has no new animation to start. The fix used here is the classic reflow trick: classList.remove('bounce'), then read tile.offsetWidth (a layout property, forcing the browser to flush pending style changes synchronously), then classList.add('bounce') again. That forced read is what makes the browser treat the second add as a genuinely new animation start rather than a no-op, so every single click gets its own fresh scale-down-then-spring-back bounce, even multiple rapid clicks in a row.

The vertical slider: translating pointer Y into a 0-100% fill

This is the part a native <input type="range"> fundamentally cannot do cleanly. setupVerticalSlider() attaches pointerdown/pointermove/pointerup listeners to a track div, and on every relevant pointer event calls valueFromClientY(clientY), which does three things: reads the track's getBoundingClientRect() to get its position and height, subtracts the rect's top from the pointer's clientY to get a relative offset inside the track, and then computes 1 - (relY / rect.height) — the *inversion* is the key detail, since a lower relative Y (near the top of the track) should mean a higher value, and a relative Y near the track's bottom should mean a value near zero, the opposite of how Y coordinates normally increase downward. The result is multiplied by 100 and rounded to a clean percentage, then clamped between 0 and 100 in applyValue() before being written directly to the fill element's height style, so the colored bar visually grows from the bottom exactly where the pointer is.

Why Pointer Events and setPointerCapture, not mousedown/touchstart

Using the unified Pointer Events API means one set of listeners handles mouse, touch, and stylus input identically — no separate touch handler branch is needed. track.setPointerCapture(e.pointerId) on pointerdown is what keeps pointermove firing on the track element even if the user's finger or cursor drifts outside the narrow 46px-wide track mid-drag; without it, a fast or imprecise drag would stop updating the slider the instant the pointer left the element's bounding box, which feels broken on a control this narrow.

Entrance animation: double rAF to guarantee the transition fires

The panel starts at opacity: 0; transform: scale(0.82) in its base CSS, and the .mounted class (which triggers the spring keyframe animation) is added inside a nested pair of requestAnimationFrame calls rather than immediately on script load. A single rAF is sometimes not enough — the browser can still batch the class addition into the same style-calculation pass as the initial render, skipping the "from" state entirely and causing the animation to appear to snap instead of transition. Nesting two rAF calls guarantees the initial styles have been painted at least once before the animation-triggering class is applied, which is a reliable, dependency-free way to force an entrance animation to actually run from its starting state.