makeover-layout 0.1.0

The renderer-agnostic half of the make-family design system: what a thing IS, named as intents and relationships and never as values. Colour defers to makeover, spacing to makeover-geometry; what is left is composition.
Documentation
# makeover-layout

The renderer-agnostic half of the make-family design system.

`makeover` answers *what colour*, and varies by theme. `makeover-geometry`
answers *how much space*, and varies by density and surface. This crate answers
*what the thing is*, and varies by nothing.

## The deferral rule

A description names intents and relationships, never values. Say `Fill::Raised`,
never `#D9DDF4`. Say `Gap::Peer`, never `6px`. What is left once colour and
spacing are deferred is composition: which edges are lit, what inverts on press,
what nests in what.

The constraint that shapes it: a renderer that can only paint rectangles has to
be able to express the result. egui has no `box-shadow: inset` and one stroke per
widget with no per-side control. A terminal has box-drawing characters and one
cell of resolution, and cannot draw a two-tone lit edge at all. So this crate
names the intent, and each renderer picks an expression it can produce, including
dropping half of one.

## What is here

Depth, and only depth: `Bevel`, `Edge`, `Fill`, `Depth`. Fill and bevel are named
together, because naming them apart is what let them disagree. Every consumer had
at least one region carrying a raised bevel over a recessed fill; audiofiles
fixed it and wrote the bug down, Balanced Breakfast still had twelve of them a
year later. `Depth` makes that unrepresentable.

The vocabulary was read off audiofiles, the only implementation written by a
consumer with no CSS, then checked against both webview apps.

## What is not here yet

Badge versus chip, toast versus banner, the list row's parts, heading levels,
segmented controls, and whether a description names loading state at all. Each is
a naming decision rather than a transcription, and each is tracked as a subtask
of the extraction task. Guessing at them now is how a description becomes a
framework.

## Status

Not published. Per the sequencing decision, 0.1.0 does not go to crates.io until
a second renderer has exercised the vocabulary; a description with one renderer
is an API with extra steps. Design and open questions live in the wiki note
`makeover-layout`; the backlog is in GoingsOn under the project of the same name.

## Licence

MIT.