Collaborator Presence Bar — Free HTML CSS JS Snippet

Most "someone is typing" indicators show one generic message for the whole document or thread, which tells you almost nothing when three people are editing at once. Google Docs and Figma solve this differently: presence is shown per person, at all times — every active collaborator gets their own avatar, their own consistently-colored ring, and their own typing indicator attached directly to their face, not funneled into one shared status line. This snippet rebuilds that per-person presence model: a horizontally overlapping avatar stack where users animate in and out as they join and leave, each active user carries a distinct, consistently-reused ring color, and a typing indicator appears as a small animated dot cluster attached to the specific avatar of whoever is typing.

Why color assignment lives on the data, not on join order

The most common bug in an avatar-stack implementation is assigning colors based on array index or join order — which silently breaks the moment membership changes, because the third person to join today might be a different actual user than the third person to join tomorrow, yet they would render with the same ring color. This snippet avoids that entirely by storing each person's color directly on their static PEOPLE record at definition time, so colorFor(id) always looks up a fixed, permanent property rather than computing anything from the current online list. The result: Diego Ruiz is always the green ring, whether he is the first person online or the fifth, whether he just rejoined for the third time or has been present the whole session — consistency comes from the color living on the person, not on their position in a list.

The enter animation: why it needs two nested requestAnimationFrame calls

When a new avatar joins, join() creates the element already styled at transform: scale(0); opacity: 0 (via its base CSS class, before .enter is added) and appends it to the DOM. Simply adding the .enter class in the same synchronous call would not animate anything, because the browser would batch the initial style and the transitioning style into the same paint and never render the "before" state at all. The fix is two nested requestAnimationFrame calls: the first guarantees the browser has committed a frame with the element still at its starting scale/opacity, and the second (scheduled from inside the first) then adds .enter, guaranteeing the transition has a genuine starting point to animate from. This is the same "force a layout, then change the class" problem every CSS-transition-triggered-by-JS implementation has to solve, just solved with rAF instead of reading offsetHeight to force a synchronous reflow.

The exit animation: waiting for transitionend before touching the DOM

leave() does the mirror image correctly too, and this is where a lot of "avatar leaves the stack" implementations get subtly wrong: they remove the element from the DOM immediately, which cancels any in-flight CSS transition instantly and makes the user just vanish with no shrink or fade at all. This snippet instead adds a .leave class (triggering the shrink-and-fade transition) and only calls removeChild inside a transitionend listener, filtered to e.propertyName === 'transform' so it does not fire early from the parallel opacity transition finishing at a different time. The DOM node genuinely stays alive, still transitioning, for the full 320ms of its exit animation.

The ring pulse as a distinct signal from color alone

Every active avatar's colored ring (an absolutely positioned pseudo-ring sized slightly larger than the avatar itself, using border-color matched to the person's assigned color) runs a continuous, gentle scale-and-fade animation, independent of hover state or typing state. This is deliberately separate from the typing indicator — the ring pulse says "this person is currently present," while the typing dots say "this specific person is producing input right now." Overloading one visual signal to mean both would make it impossible to tell "online but idle" apart from "actively typing," which is exactly the distinction a collaboration tool's presence bar needs to communicate.

Per-person typing indicators, not a shared banner

setTyping(id) adds a .typing class to exactly one avatar at a time (clearing it from whoever had it previously), which reveals a small absolutely-positioned dot cluster anchored to that avatar's own bottom-right corner using ::after-style layered <span> elements with staggered animation delays. Because the indicator is a child of the specific avatar element rather than a page-level "X is typing" message, it scales naturally to any number of simultaneous collaborators without needing string concatenation logic like "Amara and 2 others are typing" — each person's status is simply visible or not, directly on their own face.