Entrance and Exit

An element that appears from nowhere breaks spatial continuity. An element that slides in from the right implies it came from somewhere — and that it can be sent back. Entrance and exit motion is how interfaces maintain a coherent sense of space.

The spatial model

Every entrance animation implies a spatial origin. Sliding in from the right implies the element lives to the right of the current view. Rising from the bottom implies it was beneath the current surface. Expanding from a point implies it originated at that point. When you choose an entrance direction, you are making a spatial claim about where the element came from — and the user will expect to reverse that path to dismiss it.

Enter versus appear

Not every element needs an entrance animation. Elements that are part of the page’s initial structure should simply be present — no entrance animation. Elements that arrive in response to a user action — a dropdown opening, a panel sliding in, a modal appearing — benefit from an entrance animation that contextualises their arrival. The distinction is whether the element’s appearance is itself an event that benefits from explanation.

Fade with movement

The most versatile entrance pattern combines a short fade (opacity: 0 to 1) with a small translate (typically translateY(8px) to translateY(0) for elements entering from below, or translateY(-8px) for elements dropping in from above). The translate provides directionality; the fade softens the arrival. This combination works for almost any element and stays within the GPU-composited property set.

Exit faster than entrance

Exit animations should be shorter than entrance animations — typically by 30–50%. The user is done with the exiting element and is already focused on what comes next. A modal that dismisses in the same time it took to open keeps the user waiting for the interface to get out of the way. Exit fast; enter deliberately.

Consistent exit direction

An element that entered from the right should exit to the right unless the user took a specific action that implies a different direction. If the user pressed a “back” button, the element should exit to the right (returning to where it came from) while the previous view slides back in from the left. If the user pressed a “close” button, the element can fade and scale down — returning to nothing, since it was not going anywhere specific.

Scroll-triggered entrances

Scroll-triggered animation — elements animating into view as the user scrolls — is implemented with the IntersectionObserver API:

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) entry.target.classList.add('is-visible');
  });
}, { threshold: 0.15 });

document.querySelectorAll('[data-animate]').forEach(el => observer.observe(el));

The element starts in its hidden state via CSS and the .is-visible class triggers the transition:

[data-animate] {
  opacity: 0;
  transform: translateY(16px);
  transition: opacity 400ms ease-out, transform 400ms ease-out;
}
[data-animate].is-visible { opacity: 1; transform: none; }

@media (prefers-reduced-motion: reduce) {
  [data-animate] { opacity: 1; transform: none; }
}

Two important constraints: respect prefers-reduced-motion by showing elements immediately without animation (as above), and do not animate elements that are already visible on page load — triggering an entrance on content the user can already see is disorienting.

The takeaway

Choose entrance directions based on spatial logic, not aesthetic preference. Pair translate with opacity for smooth, GPU-composited entrances. Exit faster than you enter. Keep the exit direction consistent with the entrance direction unless the user’s action implies otherwise.