Cross-Document View Transitions: Scaling Across Hundreds of Elements

view transitions Cross-Document View Transitions: Scaling Across Hundreds of Elements Durgesh Rajubhai Pawar on May 25, 2026 In Part 1 , we covered the gotchas that bite you first: the deprecated meta tag that silently does nothing, the 4-second timeout that kills transitions without telling you, the image distortion that turns every aspect ratio change into silly putty, and the pagereveal / pageswap events that give you hooks into the transition lifecycle. All of that gets you from “nothing works” to “one element transitioning nicely between two pages.” Which feels great. For about five minutes. Then you try to build a product listing page with 48 cards that each need to morph into a detail view, and you realize the tutorials left out the hard part. This is where it gets real. Let’s scale this thing. Cross-Document View Transitions Series The Gotchas Nobody Mentions Scaling View Transitions Across Hundreds of Elements (You are here!) The Dream: One Line, Infinite Names In a perfect world, you’d solve the scaling problem with pure CSS. No JavaScript. No server-side loops. Just this: .card { /* Generates card-1, card-2, card-3, etc. automatically */ view-transition-name: ident("card-" sibling-index()); } That’s ident() — a CSS function proposed by Bramus (who works on Chrome) to the CSS Working Group. It takes strings, integers, or other identifiers, concatenates them, and spits out a valid CSS name. Pair it with sibling-index() , which returns an element’s position among its siblings (1, 2, 3…), and you get auto-generated unique names for every element in a list. One rule. Works for 10 cards or 10,000. The CSS doesn’t care. And it’s not just view transitions. The same pattern works for scroll-timeline-name , container-name , view-timeline-name — anywhere you need unique identifiers at scale. You could even pull names from HTML attributes with attr() instead of sibling-index() , constructing ident