惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

美团技术团队
Microsoft Azure Blog
Microsoft Azure Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
B
Blog
Y
Y Combinator Blog
博客园_首页
有赞技术团队
有赞技术团队
博客园 - Franky
腾讯CDC
G
Google Developers Blog
Recent Announcements
Recent Announcements
博客园 - 【当耐特】
D
Docker
The GitHub Blog
The GitHub Blog
MyScale Blog
MyScale Blog
H
Help Net Security
Apple Machine Learning Research
Apple Machine Learning Research
A
About on SuperTechFans
D
DataBreaches.Net
T
The Blog of Author Tim Ferriss
V
V2EX
U
Unit 42
aimingoo的专栏
aimingoo的专栏
WordPress大学
WordPress大学

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Naming many view transitions: attr() or match-element?
Leo · 2026-06-24 · via DEV Community

Leo

You have a CSS grid of cards. You want a view transition that animates every card from its old position to its new one, individually. The rule is non-negotiable: each snapshot needs a unique view-transition-name. The interesting part is no longer that requirement. It is how you assign those names without hand-writing one per card.

Bramus puts the two modern answers next to each other, prompted by Kevin Powell demonstrating one of them at CSS Day and Cyd Stumpel asking about the other in the Q&A. Both produce individual snapshots. They are not the same tool.

The attr() route

Drop a data attribute on each card, then read it from CSS:

.card {
  view-transition-name: attr(data-id type(<custom-ident>), none);
  view-transition-class: card;
}

attr() resolves data-id into a <custom-ident> and hands the result to view-transition-name. One declaration, every card gets its own name, the values come from the markup. The none fallback covers any card missing the attribute, so the cascade does not blow up on a typo.

view-transition-class: card is the second half of this snippet and the part that earns its place. With every card now carrying a unique name, you would otherwise be writing per-name ::view-transition-group() rules forever. The class lets the snapshots share one set of keyframes.

What match-element does

The newer keyword skips the data attribute entirely:

.card {
  view-transition-name: match-element;
  view-transition-class: card;
}

match-element derives a view-transition-name from the element's identity in the DOM. Same effect at the snapshot layer: each card moves on its own. You did not have to author the per-item identifier. For a hand-built layout where adding data-id to every card is a chore, that is a real ergonomic upgrade.

Where they diverge

Two snippets that look interchangeable do different things the moment you push them past a single document.

Cross-document navigations are the obvious break. match-element reads from element identity, and a node on page A is not the same node as a node on page B. The keyword has nothing stable to anchor to. attr(data-id …) keeps working because the identifier you care about lives in the markup, and the markup is the thing that crosses documents.

The other break is targeted styling. If your transition needs to single out one snapshot, say a different timing curve on a specific card, you reach for a ::view-transition-*() pseudo-selector that takes a name. Those selectors take a name. attr() gives you a name you can write down and reuse in a rule. match-element does not.

So the choice is not really "which is newer". It is whether you need the name as a value you can refer back to, in a stylesheet rule or across a navigation. If yes, the attribute route still wins. If no, the keyword saves you the markup work.

On your next view transition

Reach for match-element when the transition lives inside a single page and your animation is shared across every member of the group via view-transition-class. That is the case it was built for, and the snippet is two short lines.

Reach for attr() when the same cards need to keep their names across documents, or when you want to address a specific snapshot in a ::view-transition-*() selector by name. The data attribute is doing real work there. It is not ceremony.

Either way, treat view-transition-class as the default companion. The moment you stop hand-writing a name per card, you also stop wanting to hand-write a keyframe rule per name.