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: [css-view-transitions-2] Creating 'classes' of transition groups w3c/csswg-drafts#8319
  • Chromium (and other) comments: [css-view-transitions-2] Creating 'classes' of transition groups w3c/csswg-drafts#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:

• 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.

[LeaVerou]

We looked at this again today in a breakout. While we recognize that the use case is prevalent, we still have serious concerns about the ergonomics and syntax of this solution.

We would prefer that a solution is designed that eliminates the indirection and repetition this forces authors into. For example, one potential solution could be having the UA scan for selector arguments to ::view-transition-group() and essentially generating these rules behind the scenes.

If an alternative design is not an option, we would strongly urge the proposers to consider framing this as a separate concept and not drawing links to classes (syntactic or conceptual), as we believe this will be confusing for authors.

We'll file an issue with the CSS WG to explore these points, and we expect further discussion to happen there.

[jyasskin]

We note that this feature has consensus from the relevant working groups, and we don't think the TAG has much more to add here. Thanks for bearing with us.