JS behaviors

The inits generated

Keyboard support generated

The four behaviors that own their own key handling — everything else is native (a plain <input>, a native <dialog>'s own focus trap) or has no keyboard surface (delegation-only behaviors like alerts). Extracted from source, so it can't drift from what's actually wired.

The delegation model

Each init installs one document-level listener and resolves its target at event time; element-level listeners (a dialog's close handler) bind lazily on first use, tracked in a WeakSet — never serialized into the DOM. What you can rely on:

• Triggers may render before their dialog exists.
• Swapped-in content works without re-init.
• Clone / morph swaps can't strand stale state.

Event wiring is swap-proof; derived state is re-computed. The one HTMX-aware line in core JS is the htmx:after:swap event name a table container listens for:

// Bound table containers re-derive selection state automatically when an
// htmx:after:swap bubbles through them. Any OTHER swap mechanism calls:
import { refreshDataTable } from "@busy-office/ui/js";
refreshDataTable(container);

// Only NEW containers swapped in later need re-binding:
document.body.addEventListener("htmx:after:swap", (e) => initDataTables(e.target));

Intent events

Behaviors report user intent through DOM events — your code decides what to persist. The full generated list (name, target, when it fires, payload) is the intent-event index; it is look-up material, not something to read once.

State attributes generated

Two attributes, deliberately kept separate rather than merged into one lifecycle vocabulary — a component is either OPEN or BUSY, and conflating the two would make "is this dialog open while its save is in flight" unrepresentable in one value.

Where a component's states don't fit either shape, it gets its own attribute rather than overloading these two: data-row-state (dirty|error|warning) on data-table rows, data-day (closed|holiday|selected|today) on the calendar. A shared name across unrelated domains is a worse contract than two honestly different ones.

The Save sequence

The pattern behind every Save/Submit/Approve button in this framework's pattern catalogue, as it actually composes today — no dedicated "loading state" component, because the pieces above already cover it:

1. Idle — the button reads "Save".
2. Saving — your JS (or the HTMX bridge, for free) sets data-loading="true" and aria-busy="true" on the button, and swaps its text to "Saving…". Two channels: the text change is what a sighted user reads; aria-busy is what a screen reader announces. Neither alone is the contract.
3. Saved (or Error) — clear both attributes and restore the button's resting label, or route to your error state (a field's aria-invalid, a summary, a toast — pattern- specific, not this button's job).

Deliberately no spinner icon or success checkmark on the button itself — a real, measured decision, not an oversight: an opacity-dimmed solid-fill button drops to roughly 3.24:1 text contrast (axe color-contrast), under the 4.5:1 minimum. The button's own visible channel stays the text swap plus cursor: progress; a spinner or checkmark belongs beside or inside the button as your own markup if the pattern wants one — the framework does not force a specific glyph onto every Save action.

Import paths

import { initDialogs } from "@busy-office/ui/js";          // barrel
import { initDialogs } from "@busy-office/ui/js/behaviors/dialog.js"; // granular