Motion

Motion shows what changed and where to look. It is short, it starts at once and it never gets in the way of reading. Everything here also works with motion turned off.

Principles+

Tattva follows four principles. The right-hand columns show the closest match in three other systems. We made the pairing ourselves.

Carbon also lists no-motion alternatives and testing across screen sizes. Atlassian also lists accessible and fast. Fluent 2 also lists consistent and appealing. None of the three has a match for Calm, so it is our own addition.

Timing and easing tokens+

Four lengths of time and three easing curves. Easing is how an animation speeds up and slows down. Nothing a person presses runs longer than 400ms. One exception: a whole page or view arriving takes 520ms, on a curve that lands most of the way fast and then settles softly, so it feels calm without feeling slow.

How other systems compare

Atlassian says exits should be faster so they do not get in the way. That is why our exit is 150ms and our enter is 220ms. The more often an animation runs, the shorter and subtler it should be (NN/g).

Motion for AI states+

This list is our own summary of the sources below. It is not a published standard. The times are proposals.

Pair every waiting state with words. Tattva's shimmer and typing dots are ShimmerText and TypingIndicator.

Choosing a loading display

Do not use placeholder shapes for uploads, downloads or conversions (NN/g).

A reply appearing word by word+

Show the answer one word at a time. Add words in place and animate only fade, never height. Words already on screen must not animate again. Streamdown fades each word in over 150ms by default. Upstash limits updates to about 30 per second and stops at word ends. Both are from people who built it.

const { text, streaming } = useStreamingText(answer);
<StreamingReveal text={text} streaming={streaming} />

Scrolling while a reply is written

Keep the conversation stuck to the bottom only while the reader is within about 80px of it. Scrolling up lets go. A floating button in the thread brings them back. It shows a count when new messages arrived. Clicking it scrolls smoothly, or at once if motion is reduced. A ResizeObserver sticks it again when the size changes. When a person sends a message, the advice is to place it near the top. This comes from the shadcn message-scroller docs and other builders, not from a standard.

const { ref, atBottom, unseen, markUnseen, scrollToBottom } = useStickToBottom();
<div className="relative">
  <div ref={ref} className="h-96 overflow-y-auto"><div>…messages…</div></div>
  <JumpToLatest visible={!atBottom} count={unseen} onClick={scrollToBottom} />
</div>

Put the messages in one wrapper inside the scroller. The hook watches that wrapper grow.

Reduced motion+

Some people set their device to reduce motion. When they do, remove decorative effects. Keep feedback that tells a person what is happening or how far along it is (web.dev). Atlassian asks that the interface stays fully usable with all motion off, and that nothing flashes or sweeps.

What the standards say

• WCAG 2.3.3 (AAA): animation caused by a click or tap can be turned off unless it is essential. Its example is parallax, which can make some people dizzy.
• WCAG 2.2.2 (A): motion that starts on its own and lasts over 5 seconds, next to other content, needs a way to pause, stop or hide it. Essential loading is exempt. Flashing three or more times per second is never allowed.
• Fluent 2 suggests offering a no-motion setting and telling screen readers about changes.
• NN/g says to avoid parallax and scroll-jacking (taking over the page's scrolling).

In code, useReducedMotion() returns true or false from matchMedia("(prefers-reduced-motion: reduce)") and updates when the setting changes. Reveal, StreamingReveal, JumpToLatest and useStickToBottom all use it. As a safety net, the token file also cuts every animation to near zero.

Building it+

• Animate only transform and opacity. Avoid properties that make the browser redo layout or repaint. Use will-change sparingly, and only while an animation runs (web.dev animations guide).
• Use CSS for the patterns. Use JavaScript only for scroll handling, buffering a reply as it arrives, and watching the reduced-motion setting. This is our opinion. We found no authoritative source comparing CSS, JavaScript and Lottie.
• View Transitions work within one page in Chrome and Edge 111+, Safari 18+ and Firefox 144+. Between pages they work in Chrome and Edge 126+ and Safari 18.2+, and not in Firefox. Treat them as a bonus: check the browser supports them first, and add your own reduced-motion check.
• Use the Reveal component for arrivals. Items start 40ms apart, and the delay stops growing at the fifth item, so a group finishes inside 400ms. Both numbers are proposals.

if (document.startViewTransition && !reduced) {
  document.startViewTransition(() => update());
} else {
  update();
}

Hooks

What we could not verify+

• Material 3's emphasized easing (0.2, 0, 0, 1), short1 at 50ms and medium2 at 300ms came from search snippets only.
• We got little from Apple HIG, so we cite nothing from it.
• The AI motion list, the success switch-back time, the 40ms offset and the 220ms arrival are proposals.
• Chat scrolling advice comes from community posts and builders, not standards.
• No authoritative source compares CSS, JavaScript and Lottie for interface motion.

Sources+

• Carbon motion
• Atlassian motion
• NN/g animation duration
• NN/g skeleton screens
• NN/g response times
• Streamdown animation
• Upstash smooth streaming
• shadcn message-scroller
• WCAG 2.3.3
• WCAG 2.2.2
• web.dev prefers-reduced-motion
• web.dev animations guide
• Chrome View Transitions