Skip to content

Last updated: First published:

Automatically Assigned View Transition Names

Often, you do not really care about the specific value you assign to view-transition-name because you know how to use view-transition-class to easily assign styles to a whole… class of pseudo-elements. But you still have to come up with different view transition names for all elements of that class because the view transition names must be unique.

For a set of images like the following, you would need to define 36 view transition names.

(Click image to shuffle)

If you’re writing HTML by hand, adding view transition names takes some effort, but not much compared to everything else.

If you’re generating HTML from data, you can also generate view transition names with minimal extra work.

So beyond tech demos, what’s the real-world use case for automatically generating view transition names?

There are some scenarios where automatically generating view transition names comes in handy:

  • Separation of concerns: You could weave the view transition names assignments into your code, but you prefer to to keep it separate for better clarity or customizability.
  • Lack of control: You do not have full control over the code, e.g. because your HTML is generated from Markdown or comes from a CMS.
  • Structural mismatch: You want to target elements across different components globally.

Typically, you achieve this separation by defining view transition names in a global stylesheet rather than as inline style attributes or local CSS in components. With CSS selectors, you have a global view on your page and can select individual HTML elements as needed.

However, assigning static names to the view-transition-name property is limited to situations where you already know your elements or at least an upper bound for their number. CSS processors can’t do much to help with that either.

In reality, you don’t want to select each element individually. Instead, you want to assign unique names to a group of elements using a single selector.

Here are your options right now:

  • Useful for same-document view transitions: generate dynamic identifiers with match-element

  • Cross-document: generate dynamic identifiers with auto for elements with id properties.

  • Copy an existing unique attribute like id using attr(id type(<custom-ident>))

  • In JavaScript, do something like
    querySelectorAll("selector").forEach(e => e.style.viewTransitionName = ...)

  • Use a script like the declarative-names script
    <script src="/declarative-names.js" data-vtbag-decl="selector"/>

I would not recommend the first three approaches just yet, as of today, they don’t work reliably across all browsers. But I’m curious and looking forward to what the future has in store.

Assigning match-element or auto as a view transition name dynamically generates unique names. Where it is supported, it works well for same-document view transitions.

The view transition names generated this way depend on the browser. While Safari’s auto value seems to encourage the use of the id attribute as view transition name for cross-document view transitions, this does not work for the other browsers.

For same-document view-transitions, Safari generates rather short names, but it wont generate those for cross-document view transition.

-ua-auto-2235
-ua-auto-2236
-ua-auto-2237

What works in Safari for cross-document view transitions: Use auto on elements that have their id set. In this case, Safari/Webkit just copies the id as an view transition name, directly or with some prefix.

myid
-ua-id-myid

But that is not really auto generating view transition names, right?

Chrome’s dynamically generated names use what looks like a cryptographic hash to distinguish the owner documents of elements and a counter to distinguish the elements within the document. That way it assigns different ids during cross-document transitions.

-ua-auto-F5E19860A59EF9D0C4AAFAA1378C6862-63044
-ua-auto-F5E19860A59EF9D0C4AAFAA1378C6862-63051
-ua-auto-F5E19860A59EF9D0C4AAFAA1378C6862-63058

Auto-generation in Chrome works well for same-document and cross-document view transitions. For cross-document view transition, when using auto on elements that have their id set, Chrome also generates such cryptic names, where the hash only depends on the id, omitting the counter.

-ua-auto-A266076C3FD7C0005E7B8A3E59C387EE

Some Chrome versions conceal the random value by mapping it back to match-element on some interfaces. But that might soon change again.

Chrome offers view-transition-name: attr(id type(<custom-ident>)) as an alternative way to set view transition names. Currently, this typed attr() function is far from being baseline on all browsers.

You might wonder why copying another attribute’s value counts as a solution here. After all, you only get automatic view transition names if you have already manually set all those id attributes. Well, yes. At least it is less to type.

But it does also offer more flexibility: Once the ids are in place, you can control when to use them as view transition names using your CSS selectors. For example, you could choose to set names only on certain list elements:

ul li:nth-child(even) {
view-transition-name: attr(id type(<custom-ident>))
}

After everything we’ve covered so far: If you want a solution that reliably works across browsers and can also be used for cross-document view transitions, it seems you’re better off doing it yourself. Using document.querySelectorAll() lets you take advantage of arbitrary CSS selectors, as seen in the previous section. Plus, you have full control over the names you want to generate and assign.

Instead of building this functionality from scratch, you can use the declarative-names script from the Utensil Drawer. It also supports CSS selectors and lets you choose the names to use. Plus, you can decide whether to override existing names or keep them and even assign names randomly, creating a randomization effect like in the introductory demo on this page.

Fun fact: The introductory demo does not use the declarative-names script. Honestly, as already observed, dynamically adding view transition names is hardly extra work if you’re already generating the HTML with JavaScript.

Why bring in a fancy script to do something you can tack on while you’re cranking out the rest of the markup? It’s like hiring a sous-chef just to sprinkle salt when you’re already cooking the whole meal yourself! 😄