Crate makeover_webview 

The webview renderer for makeover_layout.

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 themes.js last wrote onto :root.

So this crate emits text naming intents, and never learns a colour. It is the deferral rule with no adapter in the way, and it is 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

This module emits component CSS and no markup, deliberately. GoingsOn has 145 innerHTML sites and Balanced Breakfast 175 createElement sites; 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.

The bevel properties are byte-identical to what both apps already hand-write, which is asserted below.

Phase B: the markup, one description at a time

form renders makeover_layout::Field, which is the half of phase B whose description is settled. It emits strings, because both apps interpolate their fields into larger string-built forms and returning nodes would rewrite those too. It owns its own escaping, on the reasoning in that module: a Rust encoder can cover element text and attribute values with one function, where the apps need four and have to choose correctly at every call site.

Rows and tables are the other half and are not here yet.

What phase A settled, and what it costs

Decided 2026-07-29 against goingson’s styles.css rather than against a component list. The useful finding there was that .btn (line 644), .card (768) and .tag, .badge (882) each hand-write the same composition, so three quarters of phase A is one rule with several names.

Two of the four decisions change how goingson looks, and adoption should not be described as a pure deletion:

• Pressed carries its fill. interactive_rules emits Depth::pressed whole. goingson presses to --surface-sunken today and will press to --surface-well, and hovers to --surface-overlay today and will hover to --hover-surface. Since surface-well inverts by theme where surface-sunken does not, a dark theme presses lighter than it hovers. That falls out of makeover’s own derivation, which says outright that surface-sunken cannot serve as a well, so if it reads wrong the answer is there and not here.
• Badges go flat. See [token_rules].

The other two: the progress trough is renderer-local and the scrollbar track was dropped (component_rules), and no class prefix ships by default, so adoption means deleting the app’s hand-written rule in the same commit that adds the generated one. .card, .badge and the tab classes all already exist in goingson, and while both rules exist the cascade order decides which wins. That is the one real risk in adopting this, and it is why the migration lands per component rather than in one commit.

Substitution, three ways

Fill::Well has no colour on makeover before 2.3.0, and each renderer answers that differently, which is the evidence that dropping Fill::fallback from the description was right:

• makeover-immediate substitutes the page in Rust.
• makeover-tui refuses to substitute and draws an edge instead, because a terminal would quantise 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.

Modules

form

Phase B, the forms half: makeover_layout::Field rendered to HTML.

list

Column layout and row structure for lists and tables.

Structs

Emit

How the emitted CSS is shaped.

Functions

bevel_properties

The custom properties both bevels resolve through.

bevel_shadow

The two-tone edge as a box-shadow value.

bevel_var

The CSS custom property holding a bevel’s composition.

component_rules

The component layer: every named thing phase A emits.

depth_class

The class name for a depth.

depth_declarations

The fill and edge declarations for a depth, as a rule body.

depth_rule

One rule giving a selector a depth, or nothing when the depth declares nothing.

depth_rules

One rule per depth: its fill and its edge, together.

fill_var

A var() reference to a fill intent, with the browser’s own fallback where the intent may be absent.

interactive_rules

Hover and pressed, for a selector that answers a click.

stylesheet

The whole phase-A stylesheet: properties, depth rules and components, with a generated-file banner.