[css-view-transitions-1] CSS selector syntax for generated elements and API names · Issue #7788 · w3c/csswg-drafts (original) (raw)

Folks at TPAC asked for the pseudo-element names to be reduced so we had a bikeshedding session, and here's what we came up with.

@fantasai @mirisuzanne I'm interested to hear your thoughts on this. We've tried to go for brevity rather than full namespacing.

"Shared element transition" becomes "View transition"

Rationale:

• "shared element" didn't seem accurate. There's no sharing of elements.
• The DOM changes, and a transition is created from the two states. The actual DOM elements aren't animated, it's just a view of them, so "view transitions".

page-transition-tag becomes

view-name

.header { /* old / page-transition-tag: header; / new */ view-name: header; }

This causes pseudos to be created so the header can be animated independently during the transition.

Rationale:

• The scope of a transition may not always be the whole "page".
• Other specs use "name" rather than "tag" to set an identifier (container-name, scroll-timeline-name).
• Using "view" because "view transition".

html::page-transition becomes

html::view-root

This is the root of the pseudo-element tree that contains all the transition parts.

Rationale:

• The scope of a transition may not always be the whole "page".
• Using "view" because "view transition".
• "root" because it's the root of the pseudo-element tree.

html::page-transition-container(header) becomes

html::view(header)

This is the pseudo-element that represents a view of an element during the transition. In this case it's the view of the 'header'. Developers target this to customize the animation. It's a child of html::view-root.

Rationale:

• Each element that's given a view-name results in the creation of one of these pseudo-elements. So view-name: header results in a html::view(header) during the transition.

html::page-transition-image-wrapper(header) becomes

html::view-image-group(header)

This wraps the view's images, providing isolation for their blending (to allow a true cross-fade). In this case it's the image-group for the 'header'. It's a child of html::view.

Rationale:

• The pseudo elements within are replaced elements, but they behave like images. They have a width, height, and an aspect ratio.

html::page-transition-outgoing-image(header) and

html::page-transition-incoming-image(header) become
html::view-before(header) and
html::view-after(header) respectively

These are the replaced elements that represent the before and after view. In their default animation, they cross-fade.

Rationale:

• Folks had difficulty mapping 'outgoing' and 'incoming'.
• 'before' and 'after' seem more intuitive, and shorter.
• The web animation API uses language like "before phase" and "after phase", although this is only in the spec and not exposed in the API.

document.createTransition() becomes

document.createViewTransition()

This is the API developers use to create a transition between states in an SPA.

Rationale:

• Although it's longer, it removes the ambiguity with CSS transitions.

Example

Taking the slide-from-the-side example from the breakout at TPAC:

Old:

::page-transition-outgoing-image(root) { animation: 500ms ease-out both slide-to-left; }

::page-transition-incoming-image(root) { animation: 500ms ease-out both slide-from-right; }

New:

::view-before(root) { animation: 500ms ease-out both slide-to-left; }

::view-after(root) { animation: 500ms ease-out both slide-from-right; }

(I've omitted the keyframes since they're the same in both)

Resulting pseudo-tree

::view-root
├ ::view(custom-ident)
|  └─ ::view-image-group(custom-ident)
|     ├─ ::view-before(custom-ident)
|     └─ ::view-after(custom-ident)
└ ::view(different-ident)
   └─ ::view-image-group(different-ident)
      ├─ ::view-before(different-ident)
      └─ ::view-after(different-ident)

(thanks @mirisuzanne!)