CSS Selector Challenge Game — Free HTML CSS JS Snippet

Most "learn CSS selectors" widgets check the player's answer against a stored string, which means a correct selector written a slightly different way is marked wrong and the whole exercise teaches memorisation rather than understanding. This snippet does the opposite: it runs the player's typed selector through the browser's own querySelectorAll against a small live DOM stage and compares the resulting element set against the set the target selector produces. Any selector that matches exactly the right elements is accepted, so a player who reaches the answer by a different valid route is rewarded rather than punished — which is the behaviour that actually builds selector intuition.

Evaluating the player's selector safely against a scoped stage

Every lookup runs as stage.querySelectorAll(selector) rather than document.querySelectorAll(selector), so a broad answer like * or div can only ever match elements inside the puzzle stage and never reaches the surrounding game chrome, the input, or the score display. The call sits inside a try/catch because a partially typed selector such as li:nth-child( throws a SyntaxError — the catch returns null, which the caller treats as "not valid yet" rather than "matches nothing", letting the input show a red border while the player is mid-keystroke without ever printing a console error.

Set equality instead of string comparison

sameSet(a, b) compares two arrays of DOM element references by length and membership: same count, and every element in the player's result also present in the target result. Because the comparison is on element identity rather than on selector text, .sold.seasonal, li.seasonal.sold and any other syntactically different selector that resolves to the same elements all grade as correct. This is the single design decision that separates a genuine selector trainer from a spelling test.

Feedback that names the failure mode

When the sets differ, the game does not simply say "wrong". It compares the two lengths and reports whether the answer was too broad (matched more elements than the target) or too narrow (matched fewer), then highlights both sets simultaneously — the player's matches with a solid .hit glow, the intended targets with a dashed .want outline. Seeing an over-matching selector light up two extra rows is far more instructive than a binary verdict, because it makes the specific over-reach visible in the same place the player is looking.

Live preview on every keystroke

An input listener re-runs the match and re-applies the .hit class as the player types, so the selector is evaluated continuously rather than only on submit. Highlights are cleared first by removing the classes from all previously marked elements, which keeps the highlight state derived purely from the current input rather than accumulating stale marks. Because querySelectorAll on a stage of a dozen elements is effectively instant, no debounce is needed — the feedback loop is tight enough that players discover how a selector behaves before they commit to it.

Level data as a single array

Each level is one object holding a plain-English goal, the markup string injected into the stage, the reference answer selector, and a hint. Adding a level is one array entry and no code change, and the same markup string is used twice — once as live DOM via innerHTML and once as readable source in the <pre> code panel — so what the player reads and what the selector runs against can never drift apart. The seven levels ramp from a bare type selector through classes, ids, chained classes, attribute selectors, :nth-child() and :not(), which is the practical core of day-to-day selector work.