import { CssKey, CssMap, CssMapBase, CssPseudoKey, CssValue, CssVarFacade, SetSurface } from "../../../types/css.types.js"; export declare function css_supports_decl(propCanon: string, value: string): boolean; export declare function make_set_surface(setProp: (prop: CssKey, v: CssValue) => TReturn): SetSurface; /** * Create the canonical custom-property facade for a style-like handle. * * This helper is backend-neutral: inline style, QUID-scoped CSS, and global CSS * can expose the same `.var.name/key/set/value` shape while wiring `set` and * `value` to their own storage scopes. */ export declare function make_css_var_facade(host: TReturn, setVar: (name: string, value: CssValue) => TReturn, readVar: (name: string) => string | undefined): CssVarFacade; /** * Fluent write surface for styles. * * A `StyleSetter` is a *handle* bound to some target (one element’s inline style, * one QUID-scoped CSS rule block, a multi-selection broadcast, etc.). * * The same API is used across backends; differences live behind `StyleSetterAdapters`. * * - `setProp` / `setMany` write values. * - `remove` deletes a single property. * - `clear` deletes all properties for the handle. * - `set` is a Proxy-based convenience surface (`setter.set.backgroundColor("...")`). * * All methods return the same `StyleSetter` for chaining. */ export type StyleSetter = { /** Proxy builder: setter.set.backgroundColor("aquamarine") */ set: SetSurface; setProp: (prop: CssKey, v: CssValue) => TReturn; setMany: (map: CssMap) => TReturn; remove: (prop: CssKey) => TReturn; clear: () => TReturn; }; /** * Backend interface used by `make_style_setter()` to perform actual writes. * * This is the “bridge” between the generic fluent API (`StyleSetter`) and a concrete style backend * (inline style via `StyleManager`, QUID-scoped stylesheet rules via `CssManager`, etc.). * * ## Invariants expected by implementers * - `propCanon` is already normalized to canonical CSS form (camelCase or `--custom-prop`). * - `value` is already rendered to a string (no additional coercion should be needed). * - `remove()` and `clear()` should be idempotent (safe to call repeatedly). * * Implementers are responsible for: * - choosing the storage/write strategy (DOM `style=""`, CSSStyleRule text, etc.), * - ensuring the target exists (or no-op if it does not), * - updating any “dirty” flags / re-render triggers used by the backend. */ export type StyleSetterAdapters = Readonly<{ /** * Apply a single *canonical* property (camelCase or --var) with a rendered string value. * `value` is already normalized/rendered when this is called. */ apply: (propCanon: string, value: string) => void; /** Remove a single *canonical* property. */ remove: (propCanon: string) => void; /** Clear all properties for this handle. */ clear: () => void; /** * Optional: allowlist keys for the proxy builder (autocomplete/constraints). * If omitted, the proxy allows any property string. */ keys?: readonly string[]; /** * Optional: handle pseudo-blocks passed via `setMany`. * * When provided, `make_style_setter` will treat entries whose keys match * `CssPseudoKey` (e.g. `_hover`, `__before`) as nested declaration maps * and route them here instead of applying them as regular properties. */ applyPseudo?: (pseudo: CssPseudoKey, decls: CssMapBase) => void; applySelector?: (pattern: string, decls: CssMapBase) => void; }>; /** * Create a `StyleSetter`: a small, fluent, backend-agnostic “write surface” for CSS style. * * ## What this is * `StyleSetter` is intentionally dumb: it holds no state and performs no DOM/CSSOM logic * itself. It only: * 1) normalizes property keys to a canonical CSS form, and * 2) renders/coerces values into strings (or “remove”), * then delegates the actual write/remove/clear work to the provided `adapters`. * * ## Where it sits in the system (wiring diagram) * - `LiveTree.style` / `TreeSelector.style` returns a StyleSetter backed by a * `StyleManager` adapter (inline style on the element). * - `LiveTree.css` / `TreeSelector.css` typically returns a StyleSetter backed by a * `CssManager` adapter (QUID-scoped rules in a stylesheet). * * This means: the same API (setProp/setMany/remove/clear and the `setter.set.*` proxy) * can be used regardless of whether the underlying mechanism is inline styles or stylesheet rules. * * ## Adapter contract (important invariants) * The adapters are called with: * - `propCanon`: already normalized to canonical CSS form (camelCase or `--custom-prop`). * - `value`: a rendered string value (already normalized/coerced by `renderCssValue()`). * * Adapters should treat these as “ready to apply”: * - `apply(propCanon, value)` must perform the write for that backend. * - `remove(propCanon)` must delete/unset that property for that backend. * - `clear()` must remove all properties for that handle/backend target. * * `make_style_setter()` guarantees: * - `null | undefined` values are treated as **remove semantics** (calls `adapters.remove()`). * - keys passed via proxy or map entries are normalized via `normalize_css_prop_key()`. * * ## Pseudo blocks in `setMany` * If `setMany` receives keys that match `CssPseudoKey`, their values are * interpreted as nested declaration maps (not as `CssValue`s). Those maps * are forwarded to `adapters.applyPseudo` when available; otherwise they * are ignored. Pseudo maps do not recurse. * * ## Proxy builder notes * The returned `setter.set` is a Proxy that converts property access into calls: * `setter.set.backgroundColor("red")` → `setProp("backgroundColor", "red")` * `setter.set["background-color"]("red")` → `setProp("background-color", "red")` * `setter.set.var("--k", 1)` → `setProp("--k", 1)` * * @param adapters Backend callbacks that implement apply/remove/clear for a specific target * (inline style, QUID stylesheet block, etc.). * * @returns A fluent `StyleSetter` that delegates mutations to the provided adapters. */ export declare function make_style_setter(host: TReturn, adapters: StyleSetterAdapters): StyleSetter; //# sourceMappingURL=style-setter.d.ts.map