/* ============================================================ THE BUTTON LAB — button.css One button, one mechanism, written once. Nothing in this file is shared with site/kit/ — no import, no shared class name for the mechanics (only the two reference-comparison blocks near the bottom reuse the OLD look on purpose, under their own `.ref-` prefix, so the new button can be held up against it). ----------------------------------------------------------------- THE SCALE Rise and sink are one signed value, --v, from -1.5 to 1.5. Zero is flat. Any button sets --v-rest / --v-hover / --v-press to any point on that scale independently. There is no separate "sink mode" — sink is just --v being negative. ----------------------------------------------------------------- ROUND 2 — two bugs, and why the structure below now has FOUR boxes instead of three. Bug 1 (hairline): the round-1 face painted its coloured fill AND its dark edge on the exact same box (background + an inset box-shadow). Same box, two paint operations, and at a fractional devicePixelRatio they round independently — the fill won by a sub-pixel on every side. Fix: the fill is now a SEPARATE, physically smaller box (.fill) nested inside the edge box (.face). Two boxes can't share a rounding error because they don't share an edge to round. Bug 2 (shadow overtake): a flush row overlaps neighbours by exactly one stroke on purpose (facts 8, and the shared-seam rule). At rest that's invisible — DOM order alone decides who wins the shared sliver. Round 1 gave a HOVERED button's whole .btn (footprint included) a boosted z-index so its rising face could clear a neighbour, and that dragged the (never-moving) footprint above the neighbour too — the neighbour's face is what's supposed to win that sliver, always, and round 1's boost let the shadow beat it instead. Fix: only .face ever gets promoted (.btn.z-top/.z-drop now target `> .face`, not the button itself). The footprint's z-index (0) is never touched by hover, so it can never outrank ANY neighbour's face (minimum z 1) — see "STACKING" below for the full reasoning. THE PROPOSAL (docs/BUTTON-LAB-BRIEF-2.md) suggested rebuilding the whole button as two independently-moving stacked shapes. Adopted in spirit, not literally: rather than two elements that move separately, .face (dark) still moves as ONE unit exactly as before — rise, sink, the shared seam and z-stacking all still work for the reasons proved in round 1 — and .fill just rides along inside it, permanently centred, permanently --sw smaller. That gets every benefit named in the proposal (no coincident edges, a shape gets the same line weight as a rectangle, stroke weight is just "how much smaller") without touching the parts of the mechanism that were already measured correct. See shapes.js for the non-rectangle case, where "smaller" has to mean a true geometric inset, not a scaled copy — the proposal's own concern about the tag's point. ----------------------------------------------------------------- THE MECHANISM (comments cite the brief's numbered MEASURED facts) .btn the FRAME. Position: relative. NEVER transforms, NEVER gets its own z-index (see STACKING). Its own box is the box everything else is measured against. .btn::before the FOOTPRINT/shadow. inset: 0, flat fill colour, no spread, z-index 0, always. When the face lifts away on rise, this static rectangle is what becomes visible as "the shadow" — a shape, not a glow. .btn::after the HIT-AREA EXTENDER (fact 6). Dead at rest. While hovered it grows toward wherever --lift has visually carried the face, so the pointer is never standing over dead space between the moved face and the still frame. .face the EDGE box. Same box as the frame at rest, painted with the edge colour as a plain background — no box-shadow ring (that was Bug 1). RISE moves this element outward; SINK never moves it, the frame is the boundary a sunk face must stay inside (fact 5). .face > .fill the FILL box. Sits centred inside .face, smaller by exactly --sw on every side (a real inset, either a CSS margin for rectangles or a true polygon offset for shapes — see shapes.js). This is what carries the button's colour, its label, and the sink lip. .fill::before the SINK LIP (facts 5, 9). Directional, leading-edge only, the theme's ink token, never moves a box. .lab the label. Travels inward on sink so "pushed in" still reads even though .fill's own box holds still. Colour discipline: nothing above is gated by :hover or :active. Fill / text / edge resolve once, from the *-rest tokens (now set on .btn itself, so the footprint can match a state colour too), and stay that way through hover and press. A real state change (selected / complete / disabled / danger) is a class — a different thing from a pointer passing over the button. ----------------------------------------------------------------- STACKING (fact 7 + Bug 2) — why nothing here sets z-index on .btn. .face always has a `transform` (identity counts), which alone makes it establish its own stacking context regardless of z-index value. .btn does NOT establish one (position:relative with z-index:auto never does). That means .face does not compare against its OWN `.btn::before` any differently than it would against a NEIGHBOURING button's .face or ::before — every footprint and every face in a row is flattened into one shared stacking order, compared by z-index first (footprint 0, face 1, boosted face 4/5) and DOM order only as a tiebreak. A footprint can never be given a z-index high enough to beat a face without ALSO giving .btn one — and the moment .btn gets a real z-index, its whole subtree (footprint included) becomes one walled unit that outranks a neighbour's individual, unwalled children entirely, which is exactly Bug 2. Keeping the promotion on .face alone means the footprint's z-index (0) can never exceed even a resting neighbour's face (1) — the shared seam always belongs to whichever face is meant to own it. ============================================================ */ /* --------------------------------------------------------------- --v REGISTRATION (round 6, item 4). Plain custom properties jump instantly between values — only properties that consume them via calc() (like `transform`, when IT carries its own `transition`) ever visibly ease. That makes "where is --v RIGHT NOW, mid-animation" unanswerable from outside, which is exactly what the sink z-order fix needs (MEASURED fact 7: z-index doesn't interpolate, so JS has to stamp a class at the moment --v crosses zero — see lab.js). Registering --v with a typed syntax makes it a first-class animatable value: a CSS transition on --v itself now genuinely interpolates, frame by frame, and every dependent calc() (--lift, --push, and everything built from them) recomputes reactively in step — see .btn below, where --v's transition lives, and the STACKING v2 note further down. ------------------------------------------------------------- */ @property --v { syntax: ""; inherits: false; initial-value: 0; } /* --------------------------------------------------------------- A section becomes a --u container by carrying this class. --u is defined with a container-query length, so nesting a narrower .rise-scope inside a wider one re-bases every button under it with no per-breakpoint media query anywhere. Falls back safely (clamps to its floor) if no container ever exists. ------------------------------------------------------------- */ .rise-scope { container-type: inline-size; container-name: rise; } /* --u lives in its OWN rule, scoped separately from the rest of the tokens. Bug caught by measurement in round 1: an earlier draft declared the whole palette on ".rise-scope" too. Since sits below , that gave body its own (light-hardcoded) copy of every token — a same-element declaration always beats an inherited one, no matter how low its specificity, so it silently overrode the dark theme applied to :root for everything inside body. --u must be re-computable per container, but colour and structure must not be re-asserted anywhere but :root, or a theme switch stops reaching into any scoped section. */ .rise-scope { --u: clamp(1.6rem, 4.6cqi, 2.75rem); } :root { --u: 1.6rem; /* safety net if nothing ever establishes a .rise-scope container */ --sw: 3px; --radius: 0px; --offset: 6px; --dur: 200ms; --dur-press: 70ms; --ease: cubic-bezier(.22, .68, .24, 1); /* the one signed scale + direction, per-button overridable */ --rise-x: -1; --rise-y: -1; --v-rest: 0; --v-hover: .75; --v-press: -.25; /* theme: Light (default) */ --ground: #FAF0D8; --panel: #FFF8E6; --panel-2: #F3E7CC; --stroke: #201A12; --text: #201A12; --muted: #6E5836; --faint: #9A8355; --accent: #FED700; --on-accent: #201A12; --ink: #201A12; --cream: #FFF8E6; --ok: #3F8A4C; --danger: #B33C24; /* round 6 — DARK MODE, A REAL DESIGN PASS. This indirection is the mechanism the redesign hangs on: --fill-default/--fg-default are what an ORDINARY (no state class) button's fill/text resolve to — see .btn's --fill/--fg below, which read these instead of hardcoding var(--accent)/var(--on-accent) directly. Light keeps the original, unchanged behaviour (every plain button is BB yellow with ink text — nothing here regresses light mode, byte for byte the same result). Dark overrides ONLY these two, right below, which is the entire redesign: no new colour VALUES anywhere, only where the existing ones get used. See the [data-theme="dark"] block for the reasoning. */ --fill-default: var(--accent); --fg-default: var(--on-accent); /* Lexend everywhere (see font.css for the @font-face), mono reserved for things that specifically need it — code, technical readouts. Round 1/2 had button labels in mono for a "kit" look; round 3 drops that in favour of the brief's explicit rule. */ --font-body: 'Lexend', system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; --font-mono: ui-monospace, "Cascadia Mono", Consolas, "SF Mono", Menlo, monospace; } /* ------------------------------------------------------------------ DARK MODE — round 6 design pass. The brief: same palette (ink, cream, BB yellow, green), different roles. Light mode's mechanical opposite — every plain button solid yellow, exactly as bright on a dark ground as on a light one — is what got called out: a big saturated fill that anchors a light page just shouts on a near-black one, and yellow that never varies stops meaning anything once it's everywhere. The redesign, in one line: on dark, ONLY a button that has genuinely EARNED colour (selected, complete, danger) gets a big saturated fill. An ordinary button is quiet — a dark panel tone with cream text and the same cream edge every button already has — so when yellow (or green, or red) does show up, it reads as a real signal instead of wallpaper. This is exactly "workshop dark": ink and cream doing most of the talking, colour spent deliberately. What did NOT move, on purpose (all still governed by --edge = --stroke, completely untouched by this pass, per the brief's own constraint that outline and shadow follow one theme token and never carry state): - the outline weight and colour (still --stroke, still ink-on-light / cream-on-dark) - the footprint/shadow (still --edge, same as the outline) - hover/press (still geometry only, still never touches colour) What DID move: - --fill-default flips from --accent (yellow) to --panel-2 — an ordinary button's fill is now a dark, slightly-raised surface instead of a colour block. --fg-default flips from --on-accent (ink, only legible on yellow) to --text (cream), which is what the new dark fill actually needs. MEASURED contrast, cream --text (#F3E0BC) on --panel-2 (#322818): ~13:1 — comfortably legible. - .is-complete's text: on light, --ok (#3F8A4C) is dark enough that --cream text works (MEASURED ~4.0:1). On dark, --ok (#7BC47F) is a much LIGHTER green — the same cream text MEASURED at only ~1.9:1 against it (fails outright), while --ink MEASURES ~8.2:1. Text colour for "complete" is the one place this pass had to become theme-conditional rather than just re-pointing a shared token, since the two themes' green sits on opposite sides of the "which text wins" line — see the override below and the matching one on THE ONE's .sel.full .nm. - .is-danger's text: same shape of problem, smaller margin. Light --danger (#B33C24) is dark enough that --cream MEASURES ~5.5:1 (--ink only ~2.9:1, fails). Dark --danger (#E0654A) is lighter — --cream drops to ~3.1:1 (borderline) while --ink MEASURES ~5.0:1, the clearly safer choice — overridden the same way, below. - .is-selected is untouched in both themes: --accent (#FED700) is bright enough that --ink text MEASURES ~12:1 against it regardless of theme, so yellow-selected reads identically light or dark — which is exactly the point: selection is the one state that should look the same everywhere, since it's not "earned" the way complete/danger are, it's just "this one, right now." ------------------------------------------------------------------ */ [data-theme="dark"] { --ground: #201A12; --panel: #2A2318; --panel-2: #322818; --stroke: #F3E0BC; --text: #F3E0BC; --muted: #D8B987; --faint: #A0824B; --cream: #FFF3D2; --ok: #7BC47F; --danger: #E0654A; /* --accent / --on-accent / --ink stay put on purpose: the accent yellow and the ink it sits on are brand colour, not surface. */ --fill-default: var(--panel-2); --fg-default: var(--text); } [data-theme="dark"] .btn.is-complete { --fg-rest: var(--ink); } [data-theme="dark"] .btn.is-danger { --fg-rest: var(--ink); } /* ============================================================ THE FRAME ============================================================ */ .btn { position: relative; display: inline-block; line-height: 0; margin: 0; padding: 0; border: 0; background: none; cursor: pointer; appearance: none; font: inherit; vertical-align: top; overflow: visible; /* Round 6 (docs/ROUND6-BRIEF.md item 2) — a `