[css-view-transitions-1] Using pseudo-elements vs shadow DOM syntax

[khushalsagar]

ViewTransitions involve the UA generating a DOM tree. A design question which has come up on #7743 and #7788 is whether this DOM tree is backed by pseudo-elements, shadow DOM or the API leaves that as an implementation detail. Filing an issue to resolve on that separately to unblock the syntax/naming discussion.

The TPAC discussion on this had the following AIs:

• ACTION: JakeA and khush to draw up pros and cons for shadow DOM vs pseudo-elements vs mixed approaches : The doc is here.
• ACTION: JakeA and khush to sketch out scoped transitions to see how they work: The doc is here.

The TLDR summary is here:

• While the html element can't have a developer provided shadow DOM, other elements can. This complicates using shadow DOM with scoped transitions where the generated tree can be hosted by any DOM element. This includes elements which have an existing developer or UA shadow DOM.

• Between using pseudo-elements and multiple shadow DOMs on an element, pseudo-elements seem easier to implement. But if multiple shadow DOMs on an element are easier to implement for an engine, we can structure the API to leave that as an implementation detail.

Proposed Resolution: Use pseudo-element syntax for UA generated DOM in ViewTransitions.

/cc @astearns @chrishtr @emilio @fantasai @jakearchibald @tabatkins @vmpstr FYI from the TPAC discussion. Apologies if I missed anyone.

[css-meeting-bot]

The CSS Working Group just discussed View Transitions: pseudo vs shadow, and agreed to the following:

• RESOLVED: Take khushal's proposal to use pseudo-element syntax for view transitions

The full IRC log of that discussion

<TabAtkins> Topic: View Transitions: pseudo vs shadow
<TabAtkins> github: https://github.com//issues/7928
<khush> Proposed Resolution: Use pseudo-element syntax for UA generated DOM in ViewTransitions.
<TabAtkins> khush: This came from a tpac discussion
<TabAtkins> khush: For the exact targeting syntax for the transition generated elements
<TabAtkins> khush: One option is tightly coupled to how pseudo-elements work
<TabAtkins> khush: Another is using ::part(), which tightly couples us to a shadow dom ipml
<TabAtkins> khush: Some are a direct CSS function on the html element
<TabAtkins> khush: would be agnostic for how it's used, pseudo or shadow
<TabAtkins> khush: So this issue is mainly to resolve on if we're okay picking a syntax that is tightly coupled with one or the other, or want a generic one?
<TabAtkins> khush: I propose pseudo-element syntax, primarily becuase a future extension is scoped transitions where these can exist on any element
<TabAtkins> khush: We can say shadow dom is usable on the root right now because authors can't put a shadow on root, but other elements *can* have shadow from authors, so that would complicate things if we used a shadow-based syntax
<astearns> ack fantasai
<TabAtkins> fantasai: I support this proposal, i think it makes sense to pick a sytnax that allows flexibility, and i think pseudo-element can do that
<TabAtkins> fantasai: also feels the most familiar to css authors who aren't as much on the programmatic side, so this works fo rme
<emilio> wfm, though I still think the initial proposal had a _lot_ of pseudos...
<TabAtkins> smfr: I think the concern was that the pseudo-element was unwielding and not user-friendly?
<TabAtkins> khush: A later option is to make that easier, smaller names
<TabAtkins> astearns: Any objections to pseudo-element syntax?
<TabAtkins> RESOLVED: Take khushal's proposal to use pseudo-element syntax for view transitions

[jakearchibald]

To clarify, this doesn't resolve on any particular pseudo-element syntax (that's happening in #7788 (comment)). The resolution is to base this on pseudo-elements rather than shadow DOM, in terms of what's developer-visible.