25 Tailwind CSS Button Groups

The thumb is one absolutely-positioned element sitting behind a row of visually-hidden radio inputs. Each visible segment is a <label> tied to a radio with for, so clicking a label checks its radio. A :has() rule on the container reads which radio is checked and sets the thumb's translate to that segment's offset — .group:has(input:nth-of-type(2):checked) .thumb{translate:100% 0}. Because the segments are equal width, each step is a clean percentage, and the spring comes from a transition with a slight-overshoot easing. The radios stay in the DOM (clipped with sr-only, never display:none) so they keep focus and arrow-key behaviour. The catch: if your segments are not equal width, a fixed percentage translate lands off-target — switch to the Anchor Positioning approach the pill-filter demo uses.

Equal-width segments let you move the indicator by a fixed percentage, but filter pills sized to their text — All, Electronics, Home & Garden — break that math, because a 25% step assumes four identical columns you no longer have. The pill-filter demo solves it with CSS Anchor Positioning: give the checked label an anchor-name via :has(), then position the single highlight against it with left:anchor(left) and width:anchor(size width). The indicator now measures the real checked button at whatever width it is, and the browser reflows it on resize for free. Without anchor support you would otherwise read offsetLeft and offsetWidth in JavaScript and write them to custom properties — so treat the anchor version as the enhancement and a measured-JS path as the fallback for older engines.

Two rules the icon toolbar and alignment-toggle demos both follow. First, every icon button carries an aria-label ("Bold", "Align left"), because the glyph alone means nothing to a screen reader, and the decorative <svg> inside gets aria-hidden. Second, pick the control that matches the behaviour: a single-select group like text alignment or the view switcher is built on radio inputs, so the arrow keys move between options and exactly one stays checked — native radio semantics, no custom key handling. A multi-toggle such as the formatting toolbar uses real <button> elements with aria-pressed flipped per toggle. The CSS-only tooltips use after:content-[attr(data-tip)], but a tooltip is not a label substitute — a tooltip only appears on hover, so keep the aria-label so the control stays named for keyboard and screen-reader users who never hover.

The monthly/yearly switch is two radio inputs above the pricing section. Each plan card renders both prices stacked, and a container-level :has() rule decides which shows: .pricing:has(#yearly:checked) .price-monthly{display:none}, with the inverse for the yearly figure. The sliding pill on the switch itself is the same translate-on-checked trick as the segmented control. Because state lives in a checked radio, it survives a form submit and needs no hydration. The common mistake is hiding the inputs with display:none — that removes them from the tab order and breaks keyboard use; clip them with sr-only instead so they stay operable. Also reserve equal height for both price nodes, or the card jumps when you switch — the two figures rarely render at the same height on their own, and an unreserved swap causes a visible layout shift.

There are two no-JS bases here. The save-options demo wraps the caret menu in <details>/<summary>: open state is the element's own open attribute and the menu is styled off details[open]. The anchor-positioned demo uses the native popover attribute with a popovertarget trigger, tethered to the button with anchor-name. Your "won't close on outside click" bug is specific to <details> — it has no light-dismiss, so clicking elsewhere leaves it open. The popover API gives you light-dismiss and Escape-to-close for free, which is exactly why it is the better base for a real menu. If you must stay on <details>, you add a small outside-click handler — but that leaves the no-JS path, so prefer the popover version wherever its browser support reaches your users.

A segmented control — the iOS switch, alignment toggle, view switcher — earns its horizontal space only for two to five mutually-exclusive options you want visible at once, like billing period or grid-vs-list. Past five it overflows on narrow screens; beyond that, use a <select> or the popover dropdown, which collapse to one line. The AI-model picker and wallet grid are deliberately not segmented: each option carries a badge, a context-window figure or a glassy card, so they use a radio-card grid that wraps with grid-cols-[repeat(auto-fit,minmax(9.5rem,1fr))]. Rule of thumb: if an option needs more than a short label, it is a radio-card grid, not a segmented control. And if the thing is a command rather than a persistent choice — Save, Deploy — reach for a split button; toggle groups represent state, buttons represent actions, and mixing the two confuses users.

The density switcher gives its moving highlight a view-transition-name. When the checked option changes, running that state change inside a view transition makes the browser snapshot the highlight's old and new positions and tween between them, so the pill appears to morph from one button to the next rather than teleport. Since state is driven by radios, the :has() rule that repositions the highlight is the real DOM change the transition captures. The design rule is progressive enhancement: in an engine without the View Transitions API the highlight still moves — it just uses the plain CSS transition instead of the cross-element morph, so nothing is gated behind the API and nothing breaks. Honour prefers-reduced-motion:reduce as well; the comet, liquid-metal and glitch demos cut their motion under that query, and the morph should drop to an instant swap too.

They split by what they track. The cursor-following spotlight updates two custom properties — --x and --y — from a pointermove listener on the group, and a radial-gradient centred on those variables paints the glow; that needs a few lines of JS because CSS cannot read the pointer position. The ripple shockwave reads the exact click coordinates the same way, then plays a scale-and-fade keyframe from that point. By contrast the conic-border pills, the glitch RGB-split and the liquid-metal thumb are pure CSS — they animate on :hover, :checked and an @property-registered angle, with no script at all. All of them must respect prefers-reduced-motion:reduce, and the pointer-driven ones should no-op on touch, where there is no hover — fall back to the static gradient so a tap still reads as a normal, legible button.