How cool would it be to add some view transitions to elements directly in the Cornerstone builder?
2 Likes
Oh yes please!
1 Like
Looks very cool. Most of my browsers still don’t have the feature, but I’ll keep an eye out for it. Not sure what controls we would need for this too. Would there need to be something in every element related to this transition name? Thanks for sending this my way.
1 Like
Thanks for considering this Charlie!
I asked ChatGPT about the View Transitions API and a possible Cornerstone integration and this is what it gave me:
What Exactly is the View Transitions API?
The View Transitions API is a browser-native way to animate between two visual states of a webpage or application — either within a single page (DOM changes) or across different pages (navigations).Think of it like a built-in, lightweight alternative to complex JavaScript animation libraries or full SPA frameworks, but with first-class browser support and much less overhead.
The View Transitions API is a modern, elegant way to animate UI changes — perfect for page transitions, >modal animations, layout shifts, and tabbed interfaces. It reduces the need for big libraries, is browser-native, and makes animations much smoother to implement and maintain.
How It Works (Simplified)
At its core, the API works like this:document.startViewTransition(() => {
// Make changes to the DOM here
});
The browser:Takes a snapshot of the current UI.
You mutate the DOM (e.g., show new content, navigate to a new page, change layout).
The browser animates between the “before” and “after” states, using pseudo-elements (like ::view-transition-old() and ::view-transition-new()).
You can style the transitions with CSS.
Where Is It Useful? (UI Use Cases)
The View Transitions API is especially useful in polished UI/UX flows. Here are key areas:
- Page Transitions (SPA or MPA)
Smooth fade, slide, or morph between pages.
Examples:
Navigating from a blog list to a post.
Changing sections on a landing page (with AJAX or client-side routing).
- Component State Changes
Example Components:Accordions
Tabs
Modal open/close
Image gallery slides
You wrap a DOM mutation like toggling a tab panel or opening a modal in startViewTransition() and animate the difference seamlessly.
- Layout Shifts or UI Rearrangements
Think “morphing cards” or animated list sorting.Examples:
A dashboard rearranging based on filters.
A pricing table switching from monthly to annual billing layout.
- Shared Element Transitions
Still somewhat manual but possible: animate an element (like an image or card) that exists in both the old and new views, transitioning between positions/sizes.Example:
Click a product card → it expands into a product detail page.
Gotchas and Considerations
Not all elements are animatable — canvas, video, iframes, and WebGL content can’t be captured.Animations are not automatic; you still need to style them via CSS pseudo-elements.
Works best with structured, predictable DOM updates.
Feature Detection
Here’s a quick way to check for support:if (document.startViewTransition) {
document.startViewTransition(() => {
// DOM updates
});
} else {
// fallback: just update DOM instantly or use CSS transitions
}
It wouldn’t be too hard for Themeco to implement support for the View Transitions API in Cornerstone, but doing it well — especially in a no-code/low-code builder — would take a bit of thoughtful integration. Here’s a breakdown of feasibility and how they might approach it:
What’s Needed to Support View Transitions API?
The View Transitions API (available in modern Chromium browsers) enables smooth animations between DOM state changes or page navigations. To support it well, Themeco would need to integrate it into both:The frontend runtime of Cornerstone-built sites, and
The builder UI, so users can enable/configure transitions per element or route.
Why It’s Relatively Easy (from a technical point of view)
Cornerstone outputs DOM fragments that are already modular and react to dynamic content. This is a good fit.They likely already have a JavaScript layer for state management and reactivity, especially for the preview and live update features. Wrapping document.startViewTransition() around those DOM updates is conceptually straightforward.
For SPAs or pseudo-SPAs (like with AJAX page loading or modal content), it can be plugged in fairly cleanly.
The Hard(er) Part: Doing It Nicely in the UI
This is where the real UX/DevEx challenge lies. Themeco would need to:
- Expose Transitions at the Component/Section/Page Level
Options like:Fade, slide, scale, custom animation.
Duration, easing, delay.
“Only animate when entering viewport” or “on page transition only.”
Could be presented in:
A “Transitions” panel per section/element.
Global settings (e.g. “Enable View Transitions for page changes”).
- Handle State Snapshotting
To use the View Transitions API well, they’d need to:Capture the before/after states of the DOM intelligently.
Avoid breaking transitions with lazy-loaded elements, iframes, or DOM mutation side-effects.
- Fallbacks for Non-supporting Browsers
Not all browsers support it yet (Safari is behind). So:They’d need graceful degradation — e.g., just use opacity/position CSS transitions.
Possibly conditionally enable the feature in the builder based on user detection.
Suggested Implementation Plan
Phase 1 (Dev-only toggle):Add View Transitions API hooks into the AJAX navigation layer.
Wrap major page/section changes in startViewTransition().
Phase 2 (Basic UI):
Create a UI panel per component/section for common animations (fade/slide).
Enable users to preview transitions directly in the Cornerstone builder.
Phase 3 (Custom Transitions):
Allow power users to inject custom keyframes or JS-based transitions.
Maybe integrate a Lottie/Framer Motion-lite style editor.
On caniuse.com the browser support is a good 80%+. It’s really only Firefox that’s lagging behind here but I believe they want to have support for it by the end of this year as well.