CSS Only Styled Radio Buttons — Custom Plan Selector, No JavaScript

Native <input type="radio"> elements can be given some cosmetic styling with accent-color, but that only recolors the browser's built-in circle — it can't turn the whole surrounding card into a selectable, visually-rich control. This snippet takes the opposite approach: hide the native input entirely and drive every visual aspect of a much larger custom control from its state.

The hide-and-restyle pattern

Each radio is positioned absolute with opacity: 0; pointer-events: none, removing it visually and from the click-hit-testing path, while leaving it in the DOM, in the tab order, and fully functional as a real form control — this matters because the form still submits a real radio value on submit, with no hidden-field synchronization trick required, unlike a from-scratch JS-only widget that has to manufacture its own form data.

Sibling combinator, not descendant, and why order matters

Every dynamic style hangs off .plan-input:checked + .plan-card — the adjacent-sibling combinator +, not the general sibling ~ used elsewhere in this batch. + matches only the *next* element immediately following, which is exactly the relationship here: the <label class="plan-card"> sits directly after its <input> in the same .plan-option wrapper, with nothing between them. This is also why the input must come *before* the label in markup order — CSS combinators only look forward through following siblings, never backward.

The dot's fill uses transform, not a background swap

.plan-dot::after is an always-present, initially scale(0) filled circle. On :checked, it scales to 1. Animating a transform: scale() rather than toggling display or swapping a background color lets the fill grow outward with a spring-like cubic-bezier easing curve — a purely visual polish detail that costs nothing extra in markup since the same ::after element exists whether checked or not; only its scale changes.

Group semantics still come from the browser

All three radios share name="plan", so checking one automatically unchecks the others — the same native mutual-exclusivity guarantee used by the tab-switcher snippet in this batch, here applied to an actual form input group rather than a purely presentational switch. That distinction matters: this component is a real form field a server can read from FormData, not a UI-only simulation of one.

Accessible focus without extra markup

.plan-input:focus-visible + .plan-card puts a visible focus outline on the *card*, not the invisible input, whenever the input receives keyboard focus and the browser determines focus should be visibly indicated (as opposed to a mouse click, which typically doesn't trigger :focus-visible). This is the same sibling-combinator trick used for the checked state, just keyed to a different pseudo-class — proof that once the hide-and-restyle pattern is in place, *any* native pseudo-class on the input (:checked, :focus-visible, :disabled, :invalid) becomes available to style the visible sibling with, for free.

Where this is the only option

Rich, custom-styled form controls are common in pricing pages and account settings screens, both of which are sometimes rendered through CMS "raw HTML" blocks or A/B testing tools that inject markup without executing arbitrary JavaScript for security reasons. Because every interactive behavior here — selection, mutual exclusivity, focus indication — comes from native input semantics plus CSS selectors, the control remains fully operable, and remains a genuine submittable form field, in exactly those constrained rendering contexts.