View Transition Classes

[vmpstr]

こんにちは TAG-さん!

I'm requesting a TAG review of View Transition Classes.

This feature introduces a new CSS property view-transition-class which allows the developer to specify one or more view transition classes. The developer can then select the ViewTransition pseudo elements using these classes (e.g. ::view-transition-group(*.class)).

This is an extension to the ViewTransition API that simplifies styling of view transition pseudo elements in a similar way that CSS classes simplify styling of regular DOM elements.

• Explainer¹ (minimally containing user needs and example code): https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-classes.md
• Specification URL: https://drafts.csswg.org/css-view-transitions-2/#view-transition-class-prop
• Tests: https://wpt.fyi/results/css/css-view-transitions?label=master&label=experimental&aligned&q=pseudo-with-classes
• User research: None.
• Security and Privacy self-review²: There are no additional security or privacy implications on top of the base View Transitions feature. Please let me know if you disagree and I'll fill out the self-review specific to this request.
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/csswg-drafts/issues with css-view-transitions-2 label
• Primary contacts (and their relationship to the specification):
  • @vmpstr, Google
  • @noamr, Google
• Organization(s)/project(s) driving the specification: Google.
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification: https://github.com/w3c/csswg-drafts/issues/8319
  • Chromium (and other) comments: https://github.com/w3c/csswg-drafts/issues/8319
  • Mozilla comments: (will update when I file request for position)
  • WebKit comments: (will update when I file request for position)
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5064894363992064

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: None.
• The group where the work on this specification is currently being done: CSSWG.
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG.
• Major unresolved issues with or opposition to this specification: None.
• This work is being funded by: Google.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback: https://github.com/w3c/csswg-drafts/issues with css-view-transitions-2 label.

[plinss]

Thanks for bearing with us. After reviewing and discussing internally, we have one question which is: did you discuss the option of using selectors and if so could you document in the explainer the reasoning for not using that approach?

We see the extra layer of indirection as being useful if view transitions can be used with multiple arbitrary pages, but it's unclear if the transitions will be generic enough in general to be reused. If the transitions need to be tailored to the specific page content then an extra layer of indirection doesn't seem useful.

[noamr]

Thanks for bearing with us.

Thanks for getting to it!

After reviewing and discussing internally, we have one question which is: did you discuss the option of using selectors and if so could you document in the explainer the reasoning for not using that approach?

Can you explain what this approach is? Happy to add to the explainer but I need to understand what that means first :)

[plinss]

Rather than defining a new kind of class, simply using a normal selector (or selector list) within the pseudo-element, e.g. ::view-transition-group(<selector>)

[noamr]

Rather than defining a new kind of class, simply using a normal selector (or selector list) within the pseudo-element, e.g. ::view-transition-group(<selector>)

That is what we are doing though

::view-transition-group(.class-name) where the class is given by the participating element using the `view-transition-class' property.

[plinss]

Your '.class-name' example isn't a regular class though, it's a view-transition-class (in which case I object to using the class syntax as it's confusing to authors, you're conflating the concept of class), what we're referring to is just using a regular class, or an Id, or any other kind of selector.

e.g.: Instead of:

div.thing1, div.thing2 { view-transition-class: my-transition }
::view-transition-group(.my-transition)

just use:

::view-transition-group(div.thing1, div.thing2)

[noamr]

Your '.class-name' example isn't a regular class though, it's a view-transition-class (in which case I object to using the class syntax as it's confusing to authors, you're conflating the concept of class), what we're referring to is just using a regular class, or an Id, or any other kind of selector.

e.g.: Instead of:

div.thing1, div.thing2 { view-transition-class: my-transition }
::view-transition-group(.my-transition)

just use:

::view-transition-group(div.thing1, div.thing2)

Ah that's not viable because for exit transitions the selector is invalid by the time the view transition starts. When @vmpstr is back from leave we'll update the explainer.

[plinss]

I don't understand that point, if a regular selector is invalid by the time the view transition starts, then wouldn't the selector that assigns the view transition class be invalid too?

[noamr]

I don't understand that point, if a regular selector is invalid by the time the view transition starts, then wouldn't the selector that assigns the view transition class be invalid too?

No! That's how view transitions work. You capture the old state, change the DOM in whatever way you want (including removing elements), capture the new state, and then run the animation. There is no guarantee that the original state of the DOM (and thus the selectors) remains valid by the time you start the animation. The tether that connects everything is the CSS properties like view-transition-name and view-transition-class that are carried over to the view transitions.

[plinss]

Right, so if you're capturing the names and classes before the transition, can't you just capture the view transition groups instead?

[plinss]

Also, have you considered simply allowing a list of view transition names in the view-transition-group selector, e.g. instead of:

::view-transition-group(list-item-1),
::view-transition-group(list-item-2),
::view-transition-group(list-item-3),
::view-transition-group(list-item-4),
::view-transition-group(list-item-5),
::view-transition-group(list-item-6),
::view-transition-group(list-item-7) {
  background: green;
}

do:

::view-transition-group(list-item-1, list-item-2, list-item-3, list-item-4, list-item-5, list-item-6, list-item-7) {
  background: green;
}```

[noamr]

Right, so if you're capturing the names and classes before the transition, can't you just capture the view transition groups instead?

You mean reading the pseudo-element styles ahead of time? Note that between the old and new document we might be changing documents, or other state might change.

e.g. html.some-state::view-transition-group(*) might be matched before the transition and not match during the transition (e.g. you call document.documentElement.classList.remove("some-state")) before the transition starts.

A lot of the current design of view transitions is based on the notion that the pseudo-elements are only created when the transition starts, we didn't want to break it for view-transition-class.

Also, have you considered simply allowing a list of view transition names in the view-transition-group selector, e.g. instead of:

::view-transition-group(list-item-1),
::view-transition-group(list-item-2),
::view-transition-group(list-item-3),
::view-transition-group(list-item-4),
::view-transition-group(list-item-5),
::view-transition-group(list-item-6),
::view-transition-group(list-item-7) {
  background: green;
}

do:

::view-transition-group(list-item-1, list-item-2, list-item-3, list-item-4, list-item-5, list-item-6, list-item-7) {
  background: green;
}```

This seems error prone when weighing against

li { view-transition-class: list-item } 

For the same reason we don't replace ordinary classes with #id1, #id2, #id3 we don't want to do that here.

[vmpstr]

I think Noam covered most of our reasons here.

I'd just like to highlight that the view-transition-name and view-transition-class are somewhat analogous to id and class in html. However, because it's set in CSS it allows us to add this property easier in some situations without requiring attribute changes. For example,

.container > div {
  view-transition-class: container-item;
}

this isn't as ergonomic if you require that the divs within the container have a common class specified on them. It may be common that this is already the case, but coupling view transitions with existing classes seems more restrictive in general.