The landing page opens with a door swinging shut, a walk to the desk, a floor and ceiling fading in, a chalkboard dropping into place, a hanging sign, and finally a wall clock starting its second hand — seven beats on a fixed schedule: door at 0.5s, walk at 0.75s, floor at 2s, ceiling at 2.15s, board at 2.35s, sign at 2.6s, clock at 2.7s. None of that sequence is orchestrated in JavaScript. Every beat is a CSS keyframe animation with its own animation-delay, and the "choreography" is nothing more than seven delays chosen to land in the right order. There's a small circular arrow in the corner that replays the whole thing on click, and the interesting part is that its code has no idea any of the above is true.
One call, not seven
A naive replay button would need to know every element with an animation, restart each one, and keep that list in sync every time a new beat gets added to the intro. This one doesn't do that. It calls hero.getAnimations({ subtree: true }) — a browser API that hands back every running Web Animation anywhere inside the hero element, whatever they are — and for each one it gets, calls .cancel() then .play(). That's the entire handler. Adding an eighth beat to the intro later needs zero changes to this function; the browser will simply hand back one more animation next time the button is clicked, because the function never counted them in the first place.
Before any of that runs, the code checks whether hero.getAnimations exists at all, and if it doesn't, it hides the button instead of wiring the click handler. A button that's visible but does nothing on an older browser is worse than no button — it invites a click and then quietly fails to deliver on it, which is a worse failure than not offering the feature at all.
The same seven beats never reach small screens
Below 900 pixels wide, the classroom stops being a side-on diorama and stacks vertically, and the intro that runs there isn't a shortened version of the desktop one — it's a different, shorter sequence with fewer beats: ceiling at 0s, floor at 0.2s, board at 0.25s, teacher at 0.65s, caption at 1.05s. The door, the wall clock, and the replay button itself are hidden outright on small screens — the sign that hangs over the lesson on desktop has nowhere to hang once the board goes full-width, so it goes the way of the door and the clock instead of clipping awkwardly. Mobile doesn't get a faster version of the same seven-beat show. It gets a five-beat show built for the layout it's actually running in.
What happens when motion is turned off
A single global rule collapses every animation and transition on the site to a duration of roughly zero the moment a visitor's device requests prefers-reduced-motion: reduce. For the hero, that means the door, the walk, the floor, the board, the sign and the clock don't play out on a compressed timeline — they resolve to their final state effectively at once, because there's no shortened version of the sequence sitting behind the full one. That's a real design choice with a real trade-off: some accessibility guidance favours keeping a brief, still-present transition rather than a hard cut, on the theory that a sudden scene change can itself be startling. We chose the simpler guarantee — an animation setting that's honoured completely, with no residual motion anyone would need to double-check — over a partially-reduced version that would need its own testing to confirm it was actually gentle enough.
What we're still unsure about
Element.getAnimations() is broadly supported in current browsers but wasn't always, which is exactly why the button checks for it and disappears rather than assuming it's there — an instructive small habit as much as a functional one, but it does mean a small number of visitors on old browsers see no replay button at all rather than a degraded one. We haven't tried to quantify how many people that actually is, because for a marketing site's decorative intro, the honest answer is that it probably isn't worth the engineering time to find out.