Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
khushalsagar opened this issue Oct 20, 2022 · 2 comments
Closed

Comments

@khushalsagar
Copy link
Member

khushalsagar commented Oct 20, 2022

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.

@khushalsagar khushalsagar added Agenda+ css-view-transitions-1 View Transitions; Bugs only labels Oct 20, 2022
@khushalsagar khushalsagar changed the title [css-view-transitions-1] Using pseudo-elements vs shadow DOM [css-view-transitions-1] Using pseudo-elements vs shadow DOM syntax Oct 20, 2022
@css-meeting-bot
Copy link
Member

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants