max / makeover-webview
git clone https://makenot.work/git/max/makeover-webview.git
git clone git@ssh.makenot.work:max/makeover-webview.git
| Name | Size | |
|---|---|---|
| examples/ | ||
| src/ | ||
| .gitignore | 99 B | |
| Cargo.toml | 1.4 KB | |
| LICENSE | 1.0 KB | |
| README.md | 2.5 KB | |
| rust-toolchain.toml | 86 B |
README
makeover-webview
The webview renderer for
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.
: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-immediatesubstitutes the page in Rust.makeover-tuirefuses 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.