# Introduction

> interanimate is a principled motion and interaction framework for the web. You describe what a moment means; it decides how it moves.

**Motion that answers back.**

interanimate is an open source animation and interaction framework for the web. It treats motion and input as one system: the person moves the interface, and the interface moves in response — continuously, interruptibly, and only when it helps.

The name is the idea. *Inter* — between. *Animate* — to give life. interanimate is about what happens *between* a person and an interface, and about the two animating each other.

<Callout title="Status">
  Specification draft (v0). This section of the docs defines the framework's core model and principles. It intentionally contains no API or implementation. Everything here is normative unless marked *informative*.
</Callout>

## Why another animation framework? [#why-another-animation-framework]

The web already has excellent animation engines. Some are declarative and state-driven; others are imperative and timeline-driven. Both answer the question *"how do I move this thing?"*

They leave a harder question to every team on every screen: **should this move at all, and if so, how should it feel?** That question gets answered inconsistently — a 500 ms fade here, a bouncy menu there, a drawer that ignores your finger, a modal that can't be dismissed until its entrance finishes, and a reduced-motion setting that is honored on one page and forgotten on the next.

The best guidance on this question exists, but it is scattered: Apple's work on fluid interfaces and springs, Google's Material motion system, IBM's productive/expressive split, decades of HCI response-time research, WCAG's motion criteria, and the craft knowledge of design engineers such as Emil Kowalski and Rauno Freiberg.

interanimate's bet is that this guidance can be **encoded as defaults** instead of left as advice. You declare the *intent* of a moment — "this is press feedback," "this panel is being revealed from that button," "the user just flicked this card" — and the framework resolves timing, physics, interruption, choreography, and accessibility from a shared set of principles. You can always override, but the right thing is the easy thing.

## What it is [#what-it-is]

- **A unified model of motion and interaction.** Animations and gestures are not separate features. A gesture is input that drives values; an animation is what those values do when the input lets go. Both share the same values, the same velocity, the same rules.
- **Springs-first.** Anything a person can touch moves with interruptible, velocity-aware physics. Timed easing remains available for effects like opacity and color, where physics adds nothing.
- **Intent-first, with escape hatches at every layer.** Start from intents, drop down to tokens, then to raw motions, then to raw values. Each layer is complete on its own.
- **Framework-agnostic.** A web-standards core, with adapters for component frameworks defined separately.
- **Accessible by construction.** Reduced-motion behavior is part of every intent's definition, not an afterthought layered on top.

## What it is not (non-goals) [#what-it-is-not-non-goals]

- **Not a 3D, WebGL, or game engine.** interanimate is about interface motion: the motion of controls, surfaces, content, and navigation.
- **Not a motion-graphics authoring tool.** Long, cinematic, scripted sequences are supported through the same primitives, but they are not the design center.
- **Not a visual style.** interanimate prescribes behavior, not appearance. It has no opinion about your colors, shapes, or brand.
- **Not a replacement for judgment.** Defaults encode good judgment for common cases. The principles exist so that you can reason about the uncommon ones.

## How to read these docs [#how-to-read-these-docs]

| Page | What it covers |
|---|---|
| [Philosophy](/docs/philosophy) | The core idea and the three pillars: Respond, Continue, Respect |
| [Principles](/docs/principles) | The twelve principles, each with its rule, rationale, and sources |
| [Core model](/docs/core-model) | The layers and vocabulary of the framework |
| [Motion model](/docs/motion-model) | Springs, channels, settling, decay, and projection |
| [Interaction model](/docs/interaction-model) | Inputs, the gesture lifecycle, hand-off, and interruption |
| [Intents](/docs/intents) | The catalog of motion intents and how each resolves |
| [Tokens](/docs/tokens) | Tempo, character, and frequency scales |
| [Choreography](/docs/choreography) | Origins, relationships, staggering, and enter/exit symmetry |
| [Accessibility](/docs/accessibility) | Motion preferences, substitution, and WCAG mapping |
| [Performance](/docs/performance) | Response budgets, frame budgets, and robustness |
| [Glossary](/docs/glossary) | Every term defined in one place |
| [Research & references](/docs/references) | The sources this specification draws on |
| [Open questions](/docs/open-questions) | Decisions not yet made |