[css-shared-element-transitions-1] Renaming and brevity

[jakearchibald]

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!)

[bramus]

Your last example uses ::view-before twice. Second occurrence should be ::view-after.

[jakearchibald]

Thanks, fixed!

[ydaniv]

View may be confusing since there's already ViewTimeline and its semantics are quite different - closer to those of viewport and viewbox. And if considering view() it may also be relevant to consider #7587.

I guess a more accurate name would be "Cross Element Transition", but that isn't helping with the brevity part 🙂 Perhaps something like cross-transition? (or x-transition?)

[tbondwilkinson]

I am quite fond the name "view"!

view-name sounds like it's the name of the view, but really it's a "part" of the overall "view" transition.

Just so I understand, why is there a need to use a new tagging system, rather than reusing one of the existing tagging systems (class, id)? I assume it's hard to support general selectors in psuedoelements here, but still wondering whether with this new DOM structure being represented in pseudoelements, rather you really do need some sort of selector syntax for that. I believe this was proposed elsewhere, I forget what the response was.

html::view(.header)

I do like the shorter names, but naming things just ::view does lose the sense of transition. ::view alone sounds like it could be static, like ::backdrop rather than something ephemeral and specific to a transition. Somewhere in between is ::view-transition

Alternate to before and after is enter and exit, which are slightly shorter.

Rather than view-before is a pseudoclass an option?

::view-transition(root):enter

[jakearchibald]

@tbondwilkinson

view-name sounds like it's the name of the view, but really it's a "part" of the overall "view" transition.

view-part-name may be more accurate, but longer.

Just so I understand, why is there a need to use a new tagging system, rather than reusing one of the existing tagging systems (class, id)?

I don't think setting a class or an ID on an element means it should be a seperate part in an animated transition. That isn't what those things semantically mean. And with class especially, it would cause an explosion of layers, since it's extremely common for an element to have a class.

It's common to want to differ the animation based on:

• Viewport width
• User preference (eg prefers-reduced-motion)
• Cascade (like a class name on the root element may influence whether a descendant is a seperate part of an animation)

This is trivial with CSS (@media, the cascade), but really really had to do with attributes.

Besides, this is very much a 'design' feature, so it semantically fits better with CSS than DOM attributes. See also container-name and scroll-timeline-name.

but still wondering whether with this new DOM structure being represented in pseudoelements, rather you really do need some sort of selector syntax for that. I believe this was proposed elsewhere, I forget what the response was.

Yeah, we're working on a few options here. I'll create a separate issue for that. I'm waiting on Mozilla folks to review it, because I want to be sure I'm representing their proposal correctly. That shouldn't impact this naming change though.

Rather than view-before is a pseudoclass an option?

It would work, but I don't see the advantage. This would require ::view-transition(root) to match:

• the root part
• the root part's image group
• the root part's before image
• the root part's after image

…and I don't see why you'd ever want to do that.

[mirisuzanne]

Bikeshedding overall name can keep happening - short is nice, and clear is also nice, and there's probably a balance worth finding.

I'm also interested in the structure being represented. I know one of the alternatives we discussed at TPAC involved some sort of 'pseudo-element descendant combinators' to make that structure more clear, and I pushed back some on needing a whole new syntax for it. But it's true that the structure gets a bit lost in this variant.

I think that the resulting pseudo-element tree is:

::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)

My immediate instinct was to try and put some structure inside the functional notation somehow:

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

But looking at it, I'm not convinced that's a good path to take. Maybe the real gain I'm looking for here is just to associate the 'image group' with the 'before' and 'after' images a bit more clearly. Something like:

::view-root
├ ::view(custom-ident)
|  └─ ::view-image-group(custom-ident)
|     ├─ ::view-image-start(custom-ident)
|     └─ ::view-image-end(custom-ident)
...

or:

::view-root
├ ::view(custom-ident)
|  └─ ::view-group(custom-ident)
|     ├─ ::view-start(custom-ident)
|     └─ ::view-end(custom-ident)
...

So in the end, I like the direction you're going - and it maybe does just come down to a bit more bikeshedding. I kinda like start and end, since we already have before and after pseudos that mean something pretty different. But I don't feel strongly.

[tbondwilkinson]

Just so I understand, why is there a need to use a new tagging system, rather than reusing one of the existing tagging systems (class, id)?

Let me rephrase, why not have an opt-in to transitions and then reuse whatever class/id already exists on that element.

<div id="foo"></div>

#foo {
  view-transition: root;
}

Which leads to something like:

::view-transition(root #foo)::enter

[jakearchibald]

@mirisuzanne

I'm also interested in the structure being represented. I know one of the alternatives we discussed at TPAC involved some sort of 'pseudo-element descendant combinators' to make that structure more clear

Yeah, I've got a whole other doc on that with all the options that I'd love your opinion on. I'm waiting on @emilio to review it first, because I want to make sure I've represented the shadow DOM pattern correctly & fairly.

I think that the resulting pseudo-element tree is:

::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)

Yep, that's correct

I kinda like start and end, since we already have before and after pseudos that mean something pretty different. But I don't feel strongly.

Hmm, start and end feel layout-positional to me (from align-content and co). I get what you mean about ::before and ::after though.

[mirisuzanne]

Hmm, start and end feel layout-positional to me (from align-content and co). I get what you mean about ::before and ::after though.

Yeah, I agree that both have baggage. In my mind the start/end baggage is just a bit more distant, since it's not part of existing pseudo-classes? But it's maybe a small distinction.

[jakearchibald]

Both are better than incoming and outgoing anyway

[SebastianZ]

As others mentioned before, naming those pseudo-elements and the API just "view" might be too general and may lead to confusions with other features. Reading the initial renaming proposal, I immadiately thought: Why is "transition" not part of their names anymore when that's the whole point of this feature? And we are defining views that are transitioned, so maybe it should rather be "transition view"? So my take on that would be to always have transition-view-* as a prefix. I.e.

page-transition-tag becomes view-name

transition-view-name

html::page-transition becomes html::view-root

html::transition-view-root

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

html::transition-view(header)

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

html::transition-view-image-group(header)

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

html::transition-view-before(header) html::transition-view-after(header)

document.createTransition() becomes document.createViewTransition()

document.createTransitionView()

Note that I am totally aware that this makes the names mostly even longer than the original ones. Though I believe that clarity has higher priority than brevity.

Sebastian

[fantasai]

Hi @jakearchibald! I love the thought that you put into this. It's maybe obvious, but I'm missing why ::view(header) and ::view-image-group(header) are two different elements? Can we combine them?

I agree with @SebastianZ that we seem to have lost the transition aspect of the names, and maybe that's worth keeping somehow.

If you want to use pseudo-element structure to represent the nesting, maybe something like:

::transition /* root */
::transition::view(header) /* group */
::transition::view(header)::old   /* outgoing image */
::transition::view(header)::new /* incoming  image */

If not, then collapsing down the names:

::transition
::transition-view(header)
::transition-view-old(header)
::transition-view-new(header)

[jakearchibald]

@fantasai

It's maybe obvious, but I'm missing why ::view(header) and ::view-image-group(header) are two different elements? Can we combine them?

Right now, every ::view(name) is a sibling in the view root, but we're pretty sure we'll add a feature to allow a ::view(name) to be nested in another ::view(name). We've got some vague docs for that here https://github.com/WICG/shared-element-transitions/blob/main/explainer.md#nested-transition-containers.

In this model, the ::view-image-group(name) provides the blending isolation between the images, so nested :views don't get impacted by the blending.

I agree with @SebastianZ that we seem to have lost the transition aspect of the names, and maybe that's worth keeping somehow.

I'm not against that, but brevity kinda goes out the window. In some cases, like page-transition-tag to view-transition-name, it's getting longer.

If you want to use pseudo-element structure to represent the nesting…

I've got a separate analysis on that, but I'm waiting on @emilio to review it before I share it more widely. I want to make sure I'm representing the shadow DOM idea properly & fairly.

If not, then collapsing down the names:

::transition
::transition-view(header)
::transition-view-old(header)
::transition-view-new(header)

I like old and new for the image names!

Are you ok with ::transition given that CSS transitions already exist, and this feature is unrelated (it uses CSS animations, not transitions)?

[khushalsagar]

the ::view-image-group(name) provides the blending isolation between the images, so nested :views don't get impacted by the blending.

Clarifying this a bit more. Currently our DOM structure looks like this per tag:

::view(foo)
|_::view-image-group(foo)
   |_::view-old(foo)
   |_::view-new(foo)

And ::view-image-group has the isolation:isolate. If ::view doesn't have any content then ::view-image-group is a no-op and the isolation can directly be added to ::view. But there are a couple of extensions which will make ::view have other content:

1. Nesting which @jakearchibald mentioned. In that case our DOM structure could look like:

    ::view(foo)
    |_::view-image-group(foo)
    |  |_::view-old(foo)
    |  |_::view-new(foo)
    ::view(bar)
        |_::view-image-group(bar)
           |_::view-old(bar)
           |_::view-new(bar)
   

2. Content capture where we want the snapshot that goes into old/new to be limited to the element's descendants. Box decorations (like background) are kept as styles which are copied over to ::view so you effectively get the same rendering as the element. Except in this mode you can interpolate those styles instead of a cross-fade with those baked into the snapshot which happens right now. In that case ::view(foo) would have a background and blending the 2 images should happen before drawing the result into this background.

I'm good with renaming ::view-root to include the word transition so its obvious that it's related to this feature. Maybe ::view-transition-root then. Depending on the syntax we can avoid adding transition for all the new pseudos but sounds like for any property which appears outside the nested syntax we do want the word transition there?

[astearns]

transition is long and the feature actually uses animations. animation is also long. view by itself doesn’t say what is being done to the view. What about view-swap which is short, easy to spell, and says what is being done (but is vague on the details of how)

[fantasai]

Just throwing out some ideas...

Using "swap" instead of "transition" as @astearns suggested and adding an image-pair wrapper to support nesting going forward...

::swap
::swap-view(header)
::swap-view-group(header)
::swap-view-old(header)
::swap-view-new(header)

or maybe

::view-swap
::view-swap-group(header)
::view-swap-set(header)
::view-swap-old(header)
::view-swap-new(header)

(I don't quite like the confusion over whether groups or sets are outermost.)

I think View Transitions is a very natural name for this feature, though, and keeping it in the pseudo names is long but also helpful?

[khushalsagar]

I don't quite like the confusion over whether groups or sets are outermost.

Would ::swap-view-images or ::view-swap-images make that clearer? Since the only nodes underneath it would be the old and new images. The flip side is, it can be odd for a single node to have plural images in the name.

I think View Transitions is a very natural name for this feature, though, and keeping it in the pseudo names is long but also helpful?

Between transition and swap, I like transition better too. It's not using CSS transitions but it's conceptually doing something similar.

[jakearchibald]

(on holiday, so sorry for the brief comment)

Yeah, "swap" to me sounds like the opposite of a transition. As "the visual state just swaps, rather than transitions".

[jakearchibald]

@fantasai

I think View Transitions is a very natural name for this feature, though, and keeping it in the pseudo names is long but also helpful?

Yeah, I'm thinking:

view-transition-name:

::view-transition-root
::view-transition(name)
::view-transition-images(name)
::view-transition-old(name)
::view-transition-new(name)

document.createViewTransition();

It doesn't do much for brevity, but I think it's pretty descriptive.

I've gone with ::view-transition(header) for brevity, since it'll be more common to select that than the root, which I've given ::view-transition-root.

[fantasai]

@jakearchibald That looks pretty self-consistent! A couple minor things I'd modify:

• We cold drop -root, and just have ::view-transition without parens be the root
• I think I like ::view-transition-set better than ::view-transition-images

So

view-transition-name:

::view-transition
::view-transition(name)
::view-transition-set(name)
::view-transition-old(name)
::view-transition-new(name)

document.createViewTransition();

How well does this structure work with your nesting proposal?

[khushalsagar]

We cold drop -root, and just have ::view-transition without parens be the root

That makes things ambiguous. Especially because we do want the function syntax to allow selecting all pseudo-elements for a particular type. For example:

::view-transition
::view-transition(*)
::view-transition-set(*)
::view-transition-old(*)
::view-transition-new(*)

The fact that ::view-transition(*) and ::view-transition selects different elements is not intuitive. ::view-transition-root is longer but better in this regard.

document.createViewTransition();

See related discussion in #7828, is document.transition() or document.transitionView() better to make it obvious that it also starts the transition (like element.animate()).

How well does this structure work with your nesting proposal?

Nesting could allow us to drop the transition word since it would be obvious in the syntax:

::view-transition-root
::view-transition-root::view(name)
::view-transition-root::view(name)::view-set
::view-transition-root::view(name)::view-set::view-old
::view-transition-root::view(name)::view-set::view-new

But the css function syntax in the first one seems much simpler to directly target these elements. Do you think it's better to just go with those? If we do resolve on backing these with a pseudo-element tree (instead of shadow DOM) then the nested syntax will work naturally (similar to other pseudo-elements) but with the longer name. I think that's fine since developers will likely use the function syntax.

::view-transition-root::view-transition(name)::view-transition-set::view-transition-old

[astearns]

Yeah, "swap" to me sounds like the opposite of a transition. As "the visual state just swaps, rather than transitions".

That’s fair. I am just throwing out shorter, vaguer options to test out the theory that view-transition is the best we can do. What about view-change?

[fantasai]

Nesting could allow us to drop the transition word since it would be obvious in the syntax:

I was referring to the proposal described in https://github.com/w3c/csswg-drafts/issues/7788#issuecomment-1261074637 not actually structuring the pseudo-elements.

If we're going to use pseudo-element structure, we should drop a lot more of the redundancies in the pseudo-element names, since they'll be scoped by their parent.

E.g.

::transition
::transition::view(name)
::transition::view(name)::set
::transition::view(name)::set::old
::transition::view(name)::set::new

The main concern I have is how this all plays with the nested transitions extension.

[khushalsagar]

The main concern I have is how this all plays with the nested transitions extension.

The nested transition extension shouldn't be an issue with this. We have 2 selector options, the chaining pseudo-element syntax that you mentioned above. With nested transition, the chaining syntax would look something like:

::transition::view(name)::view(name-child)::view(name-granchild)::set::old

Would it be fair to converge on a name with the assumption that a redundant prefix will be present depending on whether we shorter CSS functions or only the long pseudo-element chaining selector. Your comment above captures the chaining version. Same thing but with CSS function that has an extra "transition-" at the beginning:

html::transition
html::transition-view(name)
html::transition-set(name)
html::transition-old(name)
html::transition-new(name)

With nested transitions extension, html::transition-view(name) selects the corresponding view no matter where it is in the pseudo-element hierarchy.

s/transition/swap or s/transition/change in the above for Alan's name options. I'm still biased towards transitions. Partly because that's the keyword used by the same functionality in JS frameworks or native platforms.

[css-meeting-bot]

The CSS Working Group just discussed [css-shared-element-transitions-1] Renaming and brevity, and agreed to the following:

• RESOLVED: Prop: Use css-view-transitions as the shortname

The full IRC log of that discussion

<dael> Topic: [css-shared-element-transitions-1] Renaming and brevity
<dael> github: https://github.com/w3c/csswg-drafts/issues/7788
<dael> vmpstr: I can intro. We want to rename structure to something more meaningful
<dael> vmpstr: I would hope can resolve on feature name so can move to FPWD with a URL that's fixed
<dael> vmpstr: JakeA proposed view-transition prefix to most things.
<dael> vmpstr: Has been activity today discussing details
<dael> astearns: Note we can pick a fixed URL and then change syntax. We've done it before. Shouldn't look at shurt URL as unchangable thing.
<dael> fantasai: But shared-element-transitions is not the name we want. Do we use view-transitions or css-view-transitions as the URL short name?
<khush> +1 for css-view-transitions
<dael> florian: Seems reasonable. might want ot change later, but not clear we will.
<dael> astearns: Anyone argue against view-transitions?
<dael> astearns: Could resolve on css-view-transitions as the short spec name. Can also resolve to change all draft syntax.
<TabAtkins> Find with the shortname. Still not particularly happy with the syntax options, yeah
<dael> fantasai: Can we do shortname first before we dive to everything else?
<dael> astearns: Prop: Use css-view-transitions as the shortname
<dael> astearns: Obj?
<dael> RESOLVED: Prop: Use css-view-transitions as the shortname
<dael> khush: Limit discussion to spec name or also touch on names for pseudo elements? Got a good bunch of options there
<dael> astearns: Are you looking to have the discussion on call or continue on issue when there has been a little more async discussion?
<dael> vmpstr: If we can timebox discussion? Want a sense of uncertainty. I think JakeA prop names are pretty reasonable. I feel like close to resolution
<dael> astearns: Let's spend 10 min
<vmpstr> https://github.com/w3c/csswg-drafts/issues/7788#issuecomment-1266772511
<dael> vmpstr: In Jake's prop ^
<dael> vmpstr: All the pseudo elements have view-transition prefix. The property to tag elements with an id is view-transition-name. Pseudos are view-transition-root. Images old and new are subpseudo elements.
<TabAtkins> I prefer -images fwiw. The "set" doesn't mean anything afaict
<dael> vmpstr: fantasai prop view-transition-set whic makes sense. Also prop to drop root from view-transition-root but that got pushback
<dael> astearns: images vs set. Let's discuss
<dael> astearns: fantasai can you say why good to change to set?
<khush> i'm ok with set. it's smaller. :)
<dael> fantasai: It's kind represent 2 images that correspond. It's not a selector that represents each image but represents the set that correspond. Captures it's a container
<TabAtkins> q+
<dael> astearns: If this is just [missed]. If you can duplicate on old and new and get same result why set?
<dael> fantasai: Theres a wrapper for ar eason. If we were being really verbose with image-wrapper we could, but I think I prefer succinct. I like using transition-set on the wraper for 2 images
<astearns> ack TabAtkins
<dael> vmpstr: It's (image) also singular which makes it weird so set is good
<dael> TabAtkins: I like images, the plural makes it clear that it's a set. I find set ot be so content-less I have no clue what it means. This structure can be various levels. Don't know why call one a set. I vote images
<vmpstr> we also discussed -image-group
<dael> fantasai: Other thing about images is we're getting into, I don't know, the fact that it is an image we should knwo that but what we're representing is a snapshot of older and newer version
<dael> fantasai: Feels different than an image that is a replaced element
<dael> TabAtkins: The fact that it's an image in browser is important
<dael> fantasai: Images pseudo-element is not an image, it's a wrapper around 2. Since old and new doesn't have work 'image' having 'image' in wrapper is confusing
<dael> astearns: Agree set is vague and images isn't great since it's a plural. Can someone describe what this is used for?
<dael> vmpstr: It's a wrapper that sets up isolation for blending of 2 images. Not a replaced element, but container of 2 images being blended together.
<dael> astearns: What are you going to use this pseudo element for?
<dael> vmpstr: Not sure I understand. The opacity and blend modes of images will interact in it without effecting other things b/c it's isolated
<dael> fantasai: I think astearns is asking how an author is likely to use this pseudo element
<iank_> its similar to various cross-fade effects
<dael> vmpstr: I see. I don't think there's a particularly good guidance on how to use. Typically dev wants to customize container above this, the parent of wrapper, or the opacity blend of images.
<dael> vmpstr: Are some use cases where dev would want to shift container up or down. It moves left to right and container rises from below
<iank_> effect-group?
<dael> khush: Saw a demo where someone added a small animation to give a pop effect. Not what we anticipated for usage. We did it for cross fade, but that's a way we've seen devs using it.
<dael> astearns: Given this is something that we don't have explicit use cases but we know people will use it. not crucial, though. Could go a longer name like view-transition-effect-group or -image-set
<dael> fantasai: If you're going for long view-transition-old-new-set. I think it's good to not use image b/c not really an image
<TabAtkins> (it is really an image)
<fantasai> sorry, I meant conceptually
<fantasai> it is implemented as an image
<TabAtkins> I mean conceptually too
<dael> khush: one of the earlier sugegstions was view-transition-group. Is that a good compromise? Maybe view is better than set.
<dael> astearns: TabAtkins bjeciton to group?
<dael> TabAtkins: It's jsut as generic and non-meaninful. If it's not high use I would say make it longer with a name for its purpose.
<dael> TabAtkins: Where we expect style have shorter names like old new
<dael> astearns: I suggest we take this back to the issue. Let's continue with this open and come back after a bit more discussion.
<dael> astearns: I was going to suggest breaking it out, but there's good discussion so continue there
<fantasai>khush, I think wrt group, since in e.g. SVG and vector editing, "groups" are a hierarchical concept, so seems more appropriate for the higher-level grouping construct that you can nest other things inside rather than for the image-pair-wrapper

[jakearchibald]

@fantasai

If we're going to use pseudo-element structure, we should drop a lot more of the redundancies in the pseudo-element names

Yeah, I'll share my doc on that next week when I'm back from holiday. The names should translate from one system to the other.

[jakearchibald]

I like ::view-transition-images because the two things in it behave like images. They have a width, height, and aspect ratio. inset: 0 behaves the same way it would on an image.

However, this element, and the root, are the ones that I expect to be selected the least. So I'm happy with longer more descriptive names there.

Really appreciate all the effort bikeshedding this! I'll dig in more next week.

[vmpstr]

If I may summarize, there didn't seem to be an objection to generally having view-transition- prefix for the pseudo elements, but admittedly we didn't focus the discussion on this.

Most of the discussion centered around view-transition-images in this proposal

• There was some pushback on using the word "image" or "images" in here, since the element is not an image but a container. The counter proposal was view-transition-set
• The concern about "set" was that it's too generic

Some other proposals I saw in no particular order were:

• view-transition-images
• view-transition-set
• view-transition-image-set
• view-transition-effect-group

and some other combinations of those words.

In this domain, we don't expect this element to be frequently targeted, so I think a longer name is acceptable.

Personally, I'm fine with one of the four combinations: view-transition-{image,effect}-{group,set}, which seems to be most of the proposals anyway :)

Do folks have other front runners that they would like to consider? Or is there a combination of those that is particularly objectionable? I'm hoping we can reduce the set to a handful of candidates and take a vote if there is no consensus otherwise.

[khushalsagar]

Reading the notes from the discussion, I think view-transition-effect-group would address concerns with the other options. It's not using the word image which creates confusion about the elements underneath being replaced elements but not img. And avoids the too generic concern with just view-transition-group. It's longer but between brevity and clarity, we should err on the side of clarity.

@fantasai @astearns @tabatkins, any objection to view-transition-effect-group?

[tabatkins]

I continue to object to the idea that calling the images "images" is somehow confusing. The child elements are images, both literally and semantically; the image-focused object-* properties apply to them. I still don't understand what @fantasai was trying to say in her argument against it.

Calling it image would indeed be confusing and wrong, since it's a container for the images, not an image itself. But "images" is fine; the plural clearly indicates it's a container, and its children are the images being discussed.

Ultimately, as you say, this element will be rarely targeted, so its name doesn't matter that much, I just don't want us to deliberately choose a bad name for invalid reasons.