Should Rituals ship a press? (machinery is done; the design call is not)

peterswimm commented

2026-09-16 19:50:04 +00:00

Owner

@ville — a design call I deliberately did not make while building the press tier (#148 / #149).

The machinery is done and tested. native.py emits udgPressMap to Dart and Swift with substrate and pigment as token paths, not baked hex, so a press re-inks itself against the active theme at runtime. It rides the existing dart-colors and json-tokens-macos injections in sync-manifest.yml — no wiring change needed. The moment a product declares a press, it flows to Toilville_Rituals.

What is missing is the design. Choosing Rituals' screenprint identity is a brand decision, so I left it rather than inventing one.

This is what the decision looks like

Left is the press as spelwork authors it. Right is the identical token with only its two pigment vars re-pointed — terracotta and mustard on cocoa. Nothing was edited; that is what a theme switch does mechanically.

Rituals would be the first product to exercise that for real. spelwork ships light-only, so the right-hand panel above is a demonstration rather than a shipped theme. Rituals is self-contained (color_inherits_baseline: false) with 62 colours across light / dark / oldschool — it is the product that would actually prove the mechanism.

What it needs from you

Which plates. Today there are three, all SPELWork: plate.ui.rectangle (hatched frame), plate.ui.line-horizontal and plate.ui.line-diagonal (rules). Rituals may want its own.
Which pigments, per theme.
Where a press is used. press_eligible is section and column_set today.

Available to build with

Plus everything that landed after this issue was filed:

fit: slice (#149) — a hatched frame that does not distort when stretched
anchor + extent (#154) — a pull can occupy part of an element, not all of it
-rule / -band (#157) — a divider holds constant weight; a decorative strip holds constant proportion
Typed vars (#158) — every --press-* is registered with @property, so a consumer that gets something wrong lands on a declared fallback rather than a silent collapse. That one matters most for Rituals specifically: it is a Flutter/SwiftUI consumer reading a JSON manifest, so the CSS typing does not protect it — but the same type table is what a native renderer should validate against.

So a press can be a full-bleed panel, a frame that holds its corners, or a divider at one edge.

Authoring one is docs/UDG_PRESS_AUTHORING.md — about six lines of DTCG once the plates and pigments are chosen.

Not urgent and nothing is blocked: Rituals simply has no press until someone decides it should.

@ville — a design call I deliberately did not make while building the press tier (#148 / #149). **The machinery is done and tested.** `native.py` emits `udgPressMap` to Dart and Swift with `substrate` and `pigment` as **token paths**, not baked hex, so a press re-inks itself against the active theme at runtime. It rides the *existing* `dart-colors` and `json-tokens-macos` injections in `sync-manifest.yml` — **no wiring change needed**. The moment a product declares a press, it flows to `Toilville_Rituals`. **What is missing is the design.** Choosing Rituals' screenprint identity is a brand decision, so I left it rather than inventing one. ## This is what the decision looks like ![Re-inking: one token, different pigments](https://git.toilville.dev/Toilville/toilville-design/raw/commit/206a4e5/scratchpad/press-review/02-reinking.png) **Left** is the press as spelwork authors it. **Right** is the identical token with only its two pigment vars re-pointed — terracotta and mustard on cocoa. Nothing was edited; that is what a theme switch does mechanically. **Rituals would be the first product to exercise that for real.** spelwork ships light-only, so the right-hand panel above is a demonstration rather than a shipped theme. Rituals is self-contained (`color_inherits_baseline: false`) with 62 colours across **light / dark / oldschool** — it is the product that would actually prove the mechanism. ## What it needs from you 1. **Which plates.** Today there are three, all SPELWork: `plate.ui.rectangle` (hatched frame), `plate.ui.line-horizontal` and `plate.ui.line-diagonal` (rules). Rituals may want its own. 2. **Which pigments**, per theme. 3. **Where a press is used.** `press_eligible` is `section` and `column_set` today. ## Available to build with ![The two presses](https://git.toilville.dev/Toilville/toilville-design/raw/commit/206a4e5/scratchpad/press-review/01-presses.png) Plus everything that landed after this issue was filed: - **`fit: slice`** (#149) — a hatched frame that does not distort when stretched - **`anchor` + `extent`** (#154) — a pull can occupy part of an element, not all of it - **`-rule` / `-band`** (#157) — a divider holds constant *weight*; a decorative strip holds constant *proportion* - **Typed vars** (#158) — every `--press-*` is registered with `@property`, so a consumer that gets something wrong lands on a declared fallback rather than a silent collapse. That one matters most for Rituals specifically: it is a Flutter/SwiftUI consumer reading a JSON manifest, so the CSS typing does not protect it — but the same type table is what a native renderer should validate against. So a press can be a full-bleed panel, a frame that holds its corners, or a divider at one edge. **Authoring one** is `docs/UDG_PRESS_AUTHORING.md` — about six lines of DTCG once the plates and pigments are chosen. Not urgent and nothing is blocked: Rituals simply has no press until someone decides it should.