CSS Only Tab Switcher — Radio Button Hack, No JavaScript

Tabs are, structurally, a single-choice input: exactly one panel is visible at a time, which maps directly onto <input type="radio">'s native "only one option in a group can be checked" behavior. This snippet uses that mapping directly instead of simulating it with JavaScript.

Why radio, not checkbox

A checkbox hack works well for independent booleans (open/closed), but tabs are mutually exclusive — selecting one must deselect the others. Grouping several <input type="radio" name="tabs"> elements under the same name attribute gives the browser this mutual-exclusivity behavior for free: checking one radio in the group automatically unchecks every other radio sharing that name, with no JavaScript coordinating it. This is exactly the guarantee tabs need, which is why the radio hack — not the checkbox hack — is the correct primitive here.

Routing state to panels with sibling selectors

Each panel (.panel1, .panel2, .panel3) sits as a general sibling after all three radios and the .tab-list in the DOM. The rule #tab1:checked ~ .panel1 { display: block } reads as "when the radio with id tab1 is checked, show the sibling with class panel1." Because only one radio in the named group can be checked at a time, exactly one of the three ~ .panelN rules ever matches, which is what guarantees exactly one panel is visible — the same guarantee a JS tab implementation enforces manually by toggling classes, except here it falls out of native form semantics.

The sliding indicator without measuring anything

The active-tab background pill is a single absolutely-positioned .tab-indicator element, not a background color on each label. Its width is a fixed calc(33.333% - 5.333px) (accounting for the grid gaps), and each #tabN:checked ~ .tab-list .tab-indicator rule sets a different transform: translateX() value corresponding to that tab's grid column. Because transform is used instead of animating left, the indicator slides using a GPU-accelerated compositor property rather than triggering layout on every frame, and because all three possible positions are pre-computed as static calc() expressions, no JavaScript measurement of the clicked label's actual pixel position is ever needed — the layout is a fixed 3-column grid, so the three positions are knowable in advance.

Label as the click target, not the panel

Every <label for="tabN"> is bound to its radio via the for/id pair, so clicking anywhere on the visible tab button activates the correct radio through standard label-to-form-control association — the same mechanism a real <button> click would use, just routed through a hidden native input instead of a JS event handler.

Keyboard behavior comes from the browser, not from added code

Radio groups have long-standing native keyboard behavior: Tab moves focus into the group (landing on the checked radio, or the first one if none is checked), and the Arrow keys move the checked state between radios in the same name group. This snippet gets that keyboard-driven tab switching automatically, without a single keydown listener — something a from-scratch JS tab implementation has to deliberately reimplement (usually incorrectly) to match native role="tablist" behavior.

Where JavaScript genuinely cannot run

Tab interfaces are common in generated documentation (code-example tabs for different languages) and in CMS-authored marketing pages — both frequently rendered through pipelines (Markdown-to-HTML converters, sanitizing CMS renderers) that strip <script> tags for security. Because this tab switcher's entire state machine is native radio-input behavior plus CSS sibling selectors, it continues to function unchanged in exactly those stripped-script contexts, where a JS-driven tab component would render as static markup with no way to switch panels at all.