Crate hjkl_css_gui 

Adapter that maps a hjkl_css::Stylesheet onto floem View styling.

Usage:

use hjkl_css::parse;
use hjkl_css_gui::ViewCssExt;

let sheet = parse("label.prompt { color: #21d1d3; padding: 4px 8px; }")
    .expect("stylesheet parses");
let view = floem::views::label(|| "hello")
    .css(&sheet, "label", &["prompt"]);

Use .css_in(...) when the view is inside a hierarchy and combinator selectors ( , >, +, ~) need to fire:

use hjkl_css::{Node, parse};
use hjkl_css_gui::ViewCssExt;

let sheet = parse(".row .label { color: #fff; }").expect("parses");
let target = Node { element: "label", classes: &["prompt"] };
let ancestors = [Node { element: "row", classes: &[] }];
let view = floem::views::label(|| "hello")
    .css_in(&sheet, target, &ancestors, &[]);

The trait resolves the stylesheet eagerly for the base state and each supported pseudo (:hover, :focus, :active, :disabled, :selected), capturing the resolved property bags into the floem .style(|s| ...) closure. Pseudo-state blocks delegate to floem’s own .hover() / .focus() / etc. chain so floem handles the interaction wiring.

Workspace setup

floem’s Wayland layer-shell support lives on a fork (mxaddict/floem, layer-shell branch) that requires a patched floem-winit. Cargo only honours [patch.crates-io] declared at the workspace root, so hjkl-css-floem cannot ship the patch transitively. Downstream consumers building on Wayland with layer-shell must add the following to their own workspace Cargo.toml:

[patch.crates-io]
floem       = { git = "https://github.com/mxaddict/floem.git", branch = "layer-shell" }
floem-winit = { git = "https://github.com/mxaddict/winit.git", branch = "layer-shell" }

Without this block the build succeeds against stock floem 0.2 from crates.io — there is no compile-time signal — and the layer-shell features fail silently at runtime.

Traits

ViewCssExt

Extension trait that consumes a Stylesheet and applies its resolved properties — base plus every supported pseudo-state — to a floem view in one call.