Behaviors & interactivity

Interactivity is modeled, not coded. A component's behavior is described as state machines in the IR; each generator decides how to realize that behavior on its platform.

#Behaviors are state machines

A behavior tracks interaction state with a precise, formal definition — a toggle tracks on/off, a single-selection tracks which item is chosen, a presentation tracks open/closed. Because each behavior is a state machine with explicit transitions, it can't quietly drift between implementations: the machine is the source of truth, not prose.

#State drives style — explicitly

Behaviors emit states — checked, selected, open, hovered, disabled, loading, and more. Style and layout react to these explicit values, not to CSS pseudo-classes. A state-keyed override says “in the checked state, this part's fill is X” — neutrally, so every target can honor it.

#Composition

Behaviors compose. The IR carries the topology — which behavior atoms are present and how they connect — while the realization decides how they execute on a given platform. Routing one behavior's event to another, fanning out to a set, or making gestures mutually exclusive are all expressed as composition, not bespoke code.

#What behaviors don't cover

Data transforms (sorting, filtering, aggregation) stay in your data layer.
Render plumbing (portals, the rendered element, ref forwarding) is a realization concern, decided by the generator.

#Accessibility

Accessible naming and label association are authored as neutral intent — “this control is named by that text” — and the generator realizes it into the right platform attributes (for the web, aria-* and id wiring). Correctness is built into the model rather than left to each hand-written implementation.

Status

The behavior atoms, their emitted states, and the composition algebra are built and formalized as state machines. A conformance checker that flags where a target can't losslessly realize a behavior is on the roadmap.