Flexbox Alignment Game — Free HTML CSS JS Snippet

Flexbox is learned by watching things move, not by reading property tables, and the fastest way to build that intuition is a tight loop: change one value, see the layout react immediately, and know instantly whether the result is right. This snippet is a playable flexbox trainer built around exactly that loop — a stage with dashed target slots, a row of chips for flex-direction, justify-content and align-items, and balls that animate to their new positions the moment a value changes, with the equivalent CSS rule printed live underneath.

Targets drawn by flexbox itself, not by hardcoded coordinates

The stage holds two absolutely positioned layers of identical size. The lower one, the ghost layer, is a flex container filled with dashed .fx-slot circles and given the level's solution styles; the upper one holds the real .fx-ball elements and receives whatever the player has selected. Because the target positions are produced by applying real flex properties to a real container rather than by storing pixel coordinates, they stay correct at every stage width, on every device, and after any resize — there is no coordinate table to fall out of sync with the CSS. Adding a level means writing one solution object, not measuring anything.

Winning is positional, so alternative routes are accepted

isSolved() never compares the player's chosen property values against the level's solution object. It measures both layers with getBoundingClientRect(), reduces each element to its centre point, and requires every ball centre to sit within a six-pixel tolerance of some slot centre. That means any combination of properties that genuinely lands the balls on their targets counts as a win — which is the honest definition of "did you solve the layout" and prevents the game from teaching one memorised answer per level. The tolerance exists because flex distribution produces sub-pixel fractional positions that will not compare exactly equal, and because a strict equality check would fail intermittently at certain container widths.

Measuring at the right moment

Setting justifyContent on the live layer changes layout synchronously, but the check runs inside a requestAnimationFrame callback so measurement happens after the browser has settled the new layout rather than in the middle of the same task that mutated it. The balls animate to their new positions with a springy cubic-bezier transition, but the check deliberately does not wait for that animation: getBoundingClientRect() on a transitioning element returns its live interpolated box, so waiting for the transition would only delay the verdict, while measuring the settled layout box immediately is both correct and instant.

Generated CSS as the real reward

Every change re-renders a code panel containing the exact rule the player has constructed — display: flex plus the three chosen properties, formatted as copy-ready CSS. This is what converts play into transferable knowledge: the player ends each level looking at the declaration block that produced the layout they just built, in the same syntax they will type into a real stylesheet.

State kept in one object, chips derived from it

A single state object holds the three current values, and syncChips() re-derives which chip in each group is active by comparing chip.dataset.value against state[prop]. Nothing tracks selection independently in the DOM, so the visual state of the controls cannot drift from the styles actually applied to the layer — the same one-way data-flow discipline a framework would enforce, implemented in a dozen lines of vanilla JavaScript. A move counter increments only when a chip changes the value rather than on every click, so re-clicking the already-active option costs nothing.