CSS view transitions allows matching elements and morphing between them, by giving them the same name in the old and new state. This allows a lot of flexibility, but introduces a mental burden on developers, as they need to come up with unique names or a way to produce them.
One common use-case for use-transitions is animating between states, while the elements themselves don't morph to other elements. For example, animating between two states of a grid layout. In those cases, the author doesn't want the "shared element" behavior, but rather to use the view-transition mechanism (capture, create pseudo-elements, animate them) for animating elements in a way that normal transitions/animations can't.
To account for this use case, we allow the authors to specify that a particular element generates its view-transition-name.
- The keyword
selfgenerates the name from the element's identity. The name itself is not web-observable, it's like an internal token representing the element, and remaining stable. - The keyword
autogenerates the name from the element's ID, end if it doesn't exist, reverts toself.
(Note: the details/naming are discussed in the CSSWG).
The main issue with self (and auto when there is no ID present), is that they are specific to the document - they don't work for cross-document view transitions.
This is unlike all/most of the other view-transition features. However, this feature is seen as a DX convenience enhancement, and developers can always resort to using IDs or explicit names.
The alternative that is being developed in parallel is using attr() and ident() to generate an ID explicitly, e.g. ident("item-", attr(id)). This would be very flexible, but feels verbose for the common case.
- What information does this feature expose, and for what purposes?
It does not "expose" any new information.
- Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes
- Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
No
- How do the features in your specification deal with sensitive information?
N/A
- Does data exposed by your specification carry related but distinct information that may not be obvious to users?
No
- Do the features in your specification introduce state that persists across browsing sessions?
No
- Do the features in your specification expose information about the underlying platform to origins?
No
- Does this specification allow an origin to send data to the underlying platform?
No
- Do features in this specification enable access to device sensors?
No
- Do features in this specification enable new script execution/loading mechanisms?
No
- Do features in this specification allow an origin to access other devices?
No
- Do features in this specification allow an origin some measure of control over a user agent's native UI?
No
- What temporary identifiers do the features in this specification create or expose to the web?
The generated IDs are specifically not web exposed. We have to make sure there are no leaks in APIs like WAAPI or getComputedStyle.
- How does this specification distinguish between behavior in first-party and third-party contexts?
N/a
- How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
N/a
- Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes
- Do features in your specification enable origins to downgrade default security protections?
No
- What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?
N/a
- What happens when a document that uses your feature gets disconnected?
Doesn't work
- Does your feature allow sites to learn about the users use of assistive technology?
No
- What should this questionnaire have asked?
Nothing in particular.