Enum State 

#[non_exhaustive]
pub enum State {
    Focus,
    Disabled,
}

An interaction state a region can be in, beside whatever Depth it is.

Orthogonal to depth on purpose. A disabled button is still Depth::Raised and a disabled field is still a Depth::Well, so folding either member into Depth would make Depth::bevel and Depth::fill answer for something that is not a depth, and would leave disabled-button and disabled-field sharing one variant that cannot tell them apart.

Why hover and pressed are not members

The line is whether every renderer has the state to express, not whether CSS does. Hover is renderer policy and makeover-webview says so in its own header: a terminal and an immediate-mode painter have no pointer hovering over anything, and pressed already arrives through Bevel::pressed and Depth::pressed, where it belongs, because pressing is a depth inversion rather than a separate condition.

Focus and disabled are different in kind. A TUI has a focused widget and a greyed-out one; so does egui. Both were unsayable here, so all three webview consumers supplied them from outside the primitive by out-specifying rules they did not own: goingson alone carries 19 of them, and the MNW server another 21. That is the divergence this crate exists to end, arriving one layer down.

The principle this encodes

A primitive owns every state it implies. A renderer that emits a hover rule for a thing owes disabled, focus and the capability answer for that same thing, because anything less exports the completion work to N consumers who will each do it differently.

#[non_exhaustive] for the reason Fill and Depth carry it: growth must not be a lockstep event across the three renderers.

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

Focus

Keyboard focus, as distinct from the pointer having landed on something.

One ring, not one per primitive. Where the ring sits is Depth’s question and not a per-component choice: a well takes it inside its own edge and a raised surface takes it outside. That is one decision with two renderings rather than one decision per component, which is how the three apps ended up with three rings.

Disabled

Present, visible, and not answering.

Not the same as absent, and deliberately not a Fill: a disabled control keeps the surface it always had and stops responding, so what changes is its content and its interactivity rather than what it is.

Implementations

impl State

pub const fn suppresses_interaction(self) -> bool

Whether a region in this state stops answering the pointer.

Stated in the description rather than left to each renderer, on the same reasoning as Bevel::pressed: a cascade carries it for free and an immediate-mode renderer resolves it per call site, so leaving it unsaid means resolving it once per consumer and disagreeing.

Trait Implementations

impl Clone for State

fn clone(&self) -> State

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for State

impl Debug for State

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for State

impl Hash for State

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H)

where H: Hasher, Self: Sized,

Feeds a slice of this type into the given Hasher.

impl Intent for State

fn token(self) -> &'static str

The makeover intent token this resolves against.

impl PartialEq for State

fn eq(&self, other: &State) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for State