Acting icons

// Copyright (c) 2026 Bruno Delorence. MIT License.'use client';import {  useEffect,  useId,  useRef,  useState,  type CSSProperties,  type FocusEvent,  type KeyboardEvent,  type PointerEvent,} from 'react';import { DemoPointer, runDemo, type Demo } from './demo-pointer';import { Glyph, pressGlyph, type GlyphName } from './glyphs';import { SPRING } from './spring';import { useAutoplay } from './use-autoplay';import styles from './acting-icons.module.css';/* * Acting icons: a desktop app's toolbar and the glyphs it is made of, each of which acts out its * meaning when hovered and when pressed. *

/* Acting icons (acting-icons.tsx): a page of a desktop app's design system, on a warm light grey   stage, or a near-black one in the dark scheme. A toolbar of glyphs in inset caps, light and   dark, then the set, each glyph in its cap with what it does when hovered and pressed. In a   narrow stage the toolbars scroll sideways and the set falls into two columns, then one.   Colours. Every colour is a token, light first as a plain value; those that follow the scheme   come again as light-dark(light, dark) pairs inside @supports, which a build that rewrites   light-dark() for older browsers leaves as written (rewritten, the pairs would need a   color-scheme the same build had rewritten too, and on a page that sets none every colour would   drop). The stage and the set follow the color-scheme in force: the page's, or the one the   colorScheme prop sets (data-color-scheme); without light-dark() they stay light. Each toolbar   keeps its tone whatever the scheme, with colours of its own; in the dark scheme the set's caps   take the dark toolbar's. Where a dark cap's shadow has another shape, not only other colours,   its pair lists the layers of both, each transparent in the other scheme.   Memory. A phone keeps a page's pixels in tiles the width of the screen, and a tile painted   again costs a second buffer. So each cap's key is a small layer of its own (will-change), and   what changes while a glyph acts stays inside it: the face fading to its pressed look, the parts   moving. Nothing that changes while the demo plays needs a layout: the parts move by transform,   opacity and clip-path on HTML boxes around SVG drawings that never change, and the pointer is   a box that moves on its own layer. The stage does not clip its content: a rounded clip around   so many layers costs a phone more memory. */.root {

import type { CSSProperties, ReactNode } from 'react';import { EASE_OUT, KICK } from './spring';import styles from './acting-icons.module.css';/* * The twelve glyphs and how each acts out its meaning. Every glyph is drawn on a 24 grid with a * 1.7 stroke, rounded, and split into parts: the arrow and the ring it sends out, the T and its * caret, the four corners of a frame. Each part is its own small SVG in two HTML boxes, one in the * other: the outer box takes the hover pose, the inner one plays the press. The drawings never * change; only the boxes move, with transforms, opacity and clip-path, so a browser repaints a few * small boxes at most and never lays an SVG out again while a glyph acts. * * - A hover pose is a CSS transition between two transforms the part keeps in custom properties *   (--rest, --hover), on the spring of spring.ts. The cap around the glyph switches it. * - A press is played by `pressGlyph`, with the Web Animations API: a kick, the spring pulled *   towards a pose and let go, which adds itself to whatever moves already; or a path through a *   few poses (a ring that leaves, lines written in), with an ease-out. *//** A pose, on the 24 grid: moves in grid units, a turn in degrees, scales, opacity, a reveal. */type Pose = {  x?: number;  y?: number;  r?: number;

/* * The springs every glyph moves on. They share one damping ratio, 0.66: a move overshoots its * target by about 6% and settles, whatever its length. With the damping fixed, a spring's curve * is the same at every speed once its time is counted up to the moment it settles, so one curve, * sampled once, serves every duration from 180 to 460 ms: * * - SPRING, a CSS `linear()` easing, carries a glyph to its hover pose and back. A CSS transition *   starts again from wherever the glyph is when the pointer leaves halfway, so every move can be *   interrupted. * - KICK is a press: the spring is pulled towards a pose for a moment and let go, so it dips, *   comes back past its rest a little and settles. Presses play with the Web Animations API and *   add themselves to whatever already moves, so a second press lands on top of the first. *//** The damping ratio of every spring: 1 would settle without overshooting. */const DAMPING = 0.66;const WOBBLE = Math.sqrt(1 - DAMPING * DAMPING);/** A spring let go at 0 towards 1, after `t` (in units of 1 / its natural frequency). */const step = (t: number) =>  t <= 0    ? 0    : 1 -

'use client';import type { CSSProperties, Ref } from 'react';/* * The demo's pointer, and the steps that move it. A demo is a script of awaited steps: wait, * glide the pointer onto a cap, press it. Stopping the demo (the reader takes over, or it scrolls * away) ends the step in progress at once: its promise rejects, which ends the script right there, * `stopped` lets go of what the script held, and the pointer fades out. * * Nothing the pointer does needs a layout: it glides by an animation the compositor plays, the * press scales a box that keeps a transform at rest (a box that gains or loses one is laid out * again), and the arrow and the hand are HTML boxes that swap by their visibility (a change of * style inside an SVG lays the SVG out again). */export type Point = { x: number; y: number };export type Demo = {  /** Resolves after `ms`. */  wait: (ms: number) => Promise<void>;  /** Glides the pointer onto `target`: its middle, or a point given as shares of its size. */  moveTo: (target: Element, at?: Point) => Promise<void>;  /** Presses and lets go; `action` runs as the pointer goes down. */

'use client';import { useCallback, useEffect, useRef, useState } from 'react';/* * When a demo may play on its own: while part of it is on screen and the tab is visible, never * under reduced motion, and not while the reader is using it. `take()` hands it to the reader; it * takes back over `idle` ms after their last input. */export function useAutoplay<T extends HTMLElement>(idle = 6000) {  const ref = useRef<T>(null);  const [visible, setVisible] = useState(false);  const [reduced, setReduced] = useState(true);  const [taken, setTaken] = useState(false);  const timer = useRef(0);  useEffect(() => {    const element = ref.current;    if (!element) return;    let onScreen = false;    const update = () => setVisible(onScreen && !document.hidden);    const observer = new IntersectionObserver(      ([entry]) => {        onScreen = entry.isIntersecting;