CSS Only Star Rating — Radio Input Hack, No JavaScript Required

This is one of the oldest and most elegant CSS-only tricks, and it hinges entirely on a detail that's easy to miss the first time: CSS has no "select the elements *before* this one" selector, but it does have ~, which selects elements *after*. The star rating gets around the missing capability by reversing the DOM order of the stars and using flex-direction: row-reverse to put them back on screen in the expected 1-2-3-4-5 visual order.

Why the markup is written 5,4,3,2,1

To light up "this star and every star to its left" using only forward-looking sibling selectors, "to its left" has to *also mean* "later in the DOM." Writing the stars in the order 5,4,3,2,1 achieves exactly that: visually, star 1 is leftmost and star 5 is rightmost, but in the DOM, star 5 comes first and star 1 comes last. So for star 3, the stars visually to its left (2 and 1) are also its *later DOM siblings* — meaning .star3 ~ .star correctly reaches them.

Un-reversing the visual order with row-reverse

.star-rating { display: flex; flex-direction: row-reverse } flips the *rendering* order without touching the DOM order, so the browser paints star 5 on the right and star 1 on the left — the natural reading order — while the underlying sibling relationships used by the CSS selectors remain based on the reversed DOM order.

The hover-preview rule

.star-rating:hover .star:hover ~ .star reads as: "while the mouse is anywhere over the rating group, take the specific star currently under the cursor, and light it up along with every star that is its later DOM sibling." Combined with the reversed markup, "later DOM sibling of the hovered star" is precisely "every star visually to its left" — exactly the preview behavior a star rating needs. The hovered star's own color comes from the plain .star:hover half of the same selector.

The committed-selection rule, and the priority conflict it resolves

.star-rating:not(:hover) .star-input:checked + .star ~ .star applies the identical logic to whichever star is :checked, but only while the group is *not* being hovered — the :not(:hover) guard is what lets the mouse temporarily "preview" a different rating without visually disturbing the committed one, and then cleanly restores the real selection the instant the cursor leaves. Without that guard, hovering near — but not selecting — a lower rating would look identical to actually having selected it, which would be misleading.

Accessibility: five radios, one legend

Each star's <label> carries an explicit aria-label="N stars" since the visible character is just a "★" glyph, which alone tells a screen reader nothing about what it does. The group is wrapped in a <fieldset> with a visually-hidden <legend> (clipped via the standard .sr-only pattern, not display:none, so it stays in the accessibility tree) — this is how a screen reader announces "Star rating, 5 items" context before reading each radio's own label, matching how sighted users perceive the group as one cohesive control.

Where this is the only working option

Star ratings are frequently required inside review-submission widgets embedded in third-party pages, sanitized comment sections, and CMS testimonial blocks — all places that commonly strip <script> tags from user- or editor-authored HTML for security. Because every part of this widget's interactivity — the hover preview and the committed selection — is native radio-input and :hover behavior read through sibling selectors, it remains a fully working, real form field in exactly those script-stripped contexts.