CSS Radio State Machines: Multi-State Components Without JavaScript

The checkbox hack is CSS folklore—use a hidden checkbox to toggle states without JavaScript. But what happens when you need more than two states? Say you're building a multi-step wizard, a tabbed interface with four panels, or a component that cycles through seven different modes. That's where the Radio State Machine transforms a simple CSS trick into a powerful state management pattern.

The core insight is brilliant: radio buttons naturally enforce single selection within a group, making them perfect for managing mutually exclusive states. While checkboxes give you binary on/off, radio buttons give you "one of many"—exactly what you need for complex component states.

Building Your First Radio State Machine

Let's start with a practical example: a three-step form wizard. The traditional approach would involve JavaScript event handlers, state variables, and DOM manipulation. The radio state machine does this with pure HTML and CSS:

1<!-- State Controller -->
2<form class="state-controller">
3  <input type="radio" name="step" id="step1" checked>
4  <input type="radio" name="step" id="step2">
5  <input type="radio" name="step" id="step3">
6  <button type="reset">Reset</button>
7</form>
8

The CSS connects radio states to visual states using the adjacent sibling selector:

1/* Hide all panels by default */
2.panel {
3  display: none;
4}
5
6/* Show panels based on radio state */
7#step1:checked ~ .wizard .step1-panel,
8#step2:checked ~ .wizard .step2-panel,

The magic happens in the CSS selector chain: #step1:checked ~ .wizard .step1-panel. When the radio with id="step1" is checked, it selects the .step1-panel element that's a descendant of .wizard, which comes after the radio in the DOM.

Scaling to Complex States

The real power emerges when you need multiple independent state dimensions. Want a component that can be in "loading", "success", or "error" states, while also being "expanded" or "collapsed"? Use multiple radio groups:

1<form class="multi-state-controller">
2  <!-- Status: loading, success, error -->
3  <input type="radio" name="status" id="loading" checked>
4  <input type="radio" name="status" id="success">
5  <input type="radio" name="status" id="error">
6  
7  <!-- Size: collapsed, expanded -->
8  <input type="radio" name="size" id="collapsed" checked>
9  <input type="radio" name="size" id="expanded">
10</form>

Now you can target specific combinations:

1/* Error state when expanded */
2#error:checked ~ #expanded:checked ~ .component {
3  background: #ff6b6b;
4  height: 200px;
5}
6
7/* Success state when collapsed */
8#success:checked ~ #collapsed:checked ~ .component {
9  background: #51cf66;
10  height: 60px;
11}

This gives you 3 × 2 = 6 possible state combinations, all managed without JavaScript.

The Binary State Machine Pattern

For even more states, think in binary. Three radio groups with two options each (like binary bits) give you 2³ = 8 possible states. You can create state classes that represent each combination:

1/* State 000: all first radios checked */
2#bit1a:checked ~ #bit2a:checked ~ #bit3a:checked ~ .M000 {
3  display: block;
4}
5
6/* State 101: first and third checked, second unchecked */
7#bit1b:checked ~ #bit2a:checked ~ #bit3b:checked ~ .M101 {
8  display: block;
9}

With four bit groups, you get 16 states. Five groups give you 32. The pattern scales remarkably well for complex component logic.

Accessibility and Practical Considerations

There's a crucial accessibility detail: how you hide the radio inputs matters. Using display: none removes them from the accessibility tree entirely. Instead, use:

1.state-controller input[type="radio"] {
2  position: absolute;
3  opacity: 0;
4  width: 1px;
5  height: 1px;
6  overflow: hidden;
7  clip-path: polygon(0 0, 0 0, 0 0);
8}

This keeps them available to screen readers and keyboard navigation while visually hiding them.

The DOM structure constraint is real: your state controller must precede all elements it controls. This works well for page-level state management but can be limiting for deeply nested components.

When to Choose Radio State Machines

This technique shines in specific scenarios:

• Static sites where JavaScript feels like overkill for simple interactions
• Performance-critical applications where every KB of JavaScript matters
• Progressive enhancement strategies where the component should work without JS
• Educational projects that demonstrate CSS capabilities
• Components with clear, finite states like wizards, tabs, or toggles

Don't reach for this pattern when you need dynamic data binding, complex animations, or bidirectional state synchronization. JavaScript state management libraries exist for good reasons.

Why This Matters

The radio state machine isn't just a clever CSS trick—it's a glimpse into declarative programming principles. You're describing what should happen in different states, not how to transition between them. This mental model translates well to modern framework patterns and functional programming concepts.

For immediate application, try building a simple tabbed interface or accordion component using this technique. You'll gain a deeper appreciation for CSS's capabilities and add a powerful tool to your toolkit for those moments when JavaScript feels like bringing a rocket launcher to a thumb tack problem.