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.
}
}
}
}
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.