makeover-webview 0.1.0

The webview renderer for makeover-layout. Emits CSS, and is the one renderer that needs no palette: var() is the late binding, so resolution stays with the browser.
Documentation
# makeover-webview

The webview renderer for
[`makeover-layout`](https://makenot.work/git/max/makeover-layout). Emits CSS.

## The renderer that needs no palette

`makeover-immediate` and `makeover-tui` both take a `Palette`, because egui and
a terminal need an actual colour before they can put anything on screen. A
webview does not. `var(--surface-raised)` *is* the late binding, and the browser
resolves it against whatever the theme layer last wrote onto `:root`.

So this crate emits text naming intents and never learns a colour, which is the
deferral rule with no adapter in the way. It is also why the webview was always
the wrong renderer to derive a vocabulary from: it can express anything, so it
never pushes back.

## Phase A: the stylesheet only

No markup, deliberately. GoingsOn has 145 `innerHTML` sites and Balanced
Breakfast 175 `createElement` sites, so moving markup is a migration while
adopting a generated stylesheet is a deletion. The apps keep every line of their
markup and gain the classes.

```css
:root {
    --bevel-raised: inset 1px 1px 0 var(--bevel-light), inset -1px -1px 0 var(--bevel-dark);
    --bevel-inset: inset 1px 1px 0 var(--bevel-dark), inset -1px -1px 0 var(--bevel-light);
}

.raised { background: var(--surface-raised); box-shadow: var(--bevel-raised); }
.well { background: var(--surface-well, var(--surface-page)); box-shadow: var(--bevel-inset); }
.raised:active { box-shadow: var(--bevel-inset); }
```

Those two custom properties are byte-identical to what both apps already
hand-write, which is asserted in the tests. Adoption removes duplicated lines
rather than changing a pixel.

`.raised:active` is the one thing this renderer gets for free: the cascade
carries a pressed state that an immediate-mode renderer resolves per call site,
eighteen of them in audiofiles.

## Substitution, three ways

`Fill::Well` has no colour on makeover before 2.3.0, and the three renderers
answer that differently. That is the evidence that taking `Fill::fallback` out of
the description was right:

- `makeover-immediate` substitutes the page in Rust.
- `makeover-tui` refuses to substitute and draws an edge, because a terminal
  quantises the two together.
- here, CSS already has the mechanism. `var(--surface-well, var(--surface-page))`
  falls back in the browser and nothing in Rust decides anything.

## Status

Unpublished, path dep on `makeover-layout`. No consumer yet; GoingsOn goes first
when phase A is adopted, since it holds the deletion test.

`cargo run --example dump` prints the stylesheet.

## Licence

MIT.