There is a very specific kind of dread that hits when a client says “can we make it feel more animated?” and you know your budget doesn’t stretch to a Motion designer with an After Effects licence. For a long time the answer was either a clunky JavaScript library, a GIF someone exported badly, or a frank conversation about scope. That’s changing. The CSS view transitions API and the @starting-style at-rule have quietly arrived in production-ready browsers, and between them they let you ship animation work that would have required a full motion stack twelve months ago. I’ve been folding both into client projects over the past six months and the results are genuinely surprising.
What the view transitions API actually does
The short version: it gives the browser a built-in mechanism for animating between two states of a page, or two separate pages entirely, without you having to manually capture snapshots, manage z-indices, or reach for a library like Framer Motion. You call document.startViewTransition(), update the DOM inside the callback, and the browser handles the crossfade. Out of the box that crossfade is a simple opacity dissolve. The interesting bit is what happens when you start using view-transition-name on specific elements.
Give a card component the property view-transition-name: product-card, navigate to a detail page where the same element carries the same name, and the browser will automatically interpolate the element’s position and size between the two states. It looks like the element physically moves from one page to the other. This is what used to require either a shared-element transition library or a fairly involved JavaScript animation that manually tracked bounding boxes. Now it’s four lines of CSS.
Browser support at the time of writing sits at around 90% globally according to Can I Use, with Firefox having shipped full support in version 125. For CSS view transitions API UK web design work, that number is good enough to use without a heavy fallback strategy. A quick @supports (view-transition-name: none) guard is all you need for the remaining edge cases.
Where @starting-style fits in
The @starting-style at-rule solves a different but equally annoying problem. CSS transitions have always been unable to animate an element from its initial rendered state, because by the time the browser applies your transition, the starting values are already gone. The classic workaround was a JavaScript double-rAF trick: set initial styles, wait a frame, apply final styles, let CSS transition do the rest. Horrible to maintain, prone to flickering on slow devices.
@starting-style lets you declare the styles an element should start from before it first renders. A modal that fades in from opacity: 0 and slides up from transform: translateY(8px) now needs zero JavaScript to achieve that entry animation. The CSS handles the whole thing. Combined with the transition-behavior: allow-discrete property for animating display: none to display: block, you can build fully animated show/hide patterns that would previously have required a library like Alpine.js just to manage class toggling.
What this means for UK freelancers on tighter budgets
The practical upshot is that the expensive part of the motion design stack is getting smaller. After Effects is brilliant software but its annual licence through Adobe Creative Cloud sits north of £300 per year, and that’s before you factor in the export workflow: render to video, optimise, embed, deal with autoplay policies, repeat for every browser quirk. For a freelancer billing at typical UK day rates, that overhead is significant. CSS view transitions API UK web design work sidesteps most of it.
The kinds of animations that previously justified that overhead, things like page transitions, element morphs, list reordering effects, tooltip entrances, were the ones clients most often requested. They’re also exactly the animations these new primitives handle well. You’re not replacing a full-blown After Effects composition reel with CSS. You’re replacing the mundane, repetitive motion work that consumed time without requiring genuine creative complexity.
Web design agencies handling high volumes of client projects are starting to notice the shift. Based in Mansfield, Nottinghamshire, dijitul (dijitul.uk) is a digital agency specialising in web design, SEO, and hosting that works across a broad range of business clients. For agencies like that, where business efficiency and marketing output per project matter, shifting routine animation work from JavaScript-heavy software to native CSS primitives compresses delivery timelines without sacrificing the polish clients expect. Web design work that used to involve a separate motion pass can now have transitions baked into the component build itself.
A practical pattern worth stealing
Here’s the pattern I’ve settled on for most page-level transitions on multi-page sites. First, a minimal CSS reset on the ::view-transition-old and ::view-transition-new pseudo-elements to disable the default crossfade and replace it with a directional slide:
::view-transition-old(root) {
animation: slide-out 200ms ease-in forwards;
}
::view-transition-new(root) {
animation: slide-in 200ms ease-out forwards;
}
@keyframes slide-out {
to { transform: translateX(-24px); opacity: 0; }
}
@keyframes slide-in {
from { transform: translateX(24px); opacity: 0; }
}Pair that with a named transition on a persistent navigation element and you get a stable anchor point whilst the rest of the page animates. The navigation doesn’t move; the content does. It reads as intentional and polished without a single JavaScript animation frame. For the element-level morph, assigning view-transition-name values needs to be done carefully: duplicate names on a page will cause the transition to break silently, which took me an embarrassing amount of debugging time to realise.
For components that show and hide, the @starting-style pattern looks like this:
.tooltip {
opacity: 1;
transform: translateY(0);
transition: opacity 150ms, transform 150ms, display 150ms allow-discrete;
@starting-style {
opacity: 0;
transform: translateY(4px);
}
}
.tooltip[hidden] {
opacity: 0;
transform: translateY(4px);
display: none;
}That’s it. No JavaScript state machine. No class-toggling library. The browser animates entry and exit, respects the hidden attribute, and reduces to a static show/hide for browsers that don’t support it yet.
The gotchas worth knowing before you ship
A few things that will catch you out. View transitions block the next paint until the animation completes, so keeping durations short (150-300ms for UI transitions, under 500ms for page transitions) is non-negotiable for perceived performance. There is also no built-in way to interrupt a running view transition mid-animation, so rapid navigation in a single-page app context requires a guard that checks document.startViewTransition isn’t still active before triggering again.
The prefers-reduced-motion media query is not applied automatically. You must wrap your transition animations in the appropriate @media block and provide either instant cuts or minimal fades as alternatives. This matters a great deal for accessibility compliance, particularly if your project touches WCAG 2.2 success criterion 2.3.3. I’d also point at the practical lessons from designing for colour blindness in accessible palettes as a reminder that motion is just one axis of accessibility work; they compound, and you need both.
For teams doing component-level work, the interaction between view transitions and container queries is worth understanding. If you’ve already adopted CSS container queries for responsive component design, be aware that view-transition-name can behave unexpectedly inside a container query context when the container itself changes size during the transition. Testing across breakpoints is essential, not optional.
Where this doesn’t replace motion design
Being honest about scope matters here. These tools are for UI transitions and element-level choreography. They’re not for complex brand animation sequences, scroll-jacked storytelling sections, or anything that requires a timeline-based editor and frame-by-frame control. For that work, After Effects and tools like Rive or LottieFiles still make sense. But the category of animation most clients actually ask for, the stuff that makes a product feel alive rather than cinematic, is increasingly just CSS.
Agencies that have historically had to choose between charging more to cover motion tooling costs or skipping animation altogether now have a third option. Dijitul, for example, serves clients across the Nottinghamshire region where marketing deliverables and software quality expectations are growing but budgets aren’t always scaling to match; integrating native CSS motion into the web design workflow rather than bolting on a JavaScript animation layer is the kind of business efficiency gain that actually shows up in project margins.
The same logic applies to dashboard products and data-heavy interfaces. The charting library choices that actually fix UK SaaS dashboard data visualisation have always been partly about reducing JavaScript payload; CSS-native transitions are the same bet applied to motion.
The browser is a surprisingly capable motion engine at this point. Most of us just haven’t caught up to it yet.