[css-view-transitions-1] CSS selector keywords.

[khushalsagar]

Forking this from #7788 to resolve on the exact keywords used in the selector.

1. Property used on DOM elements to tag them for independent animations: view-transition-name.

2. The pseudo-element which directly originates from the root element and is the ancestor for all container elements. Options are:

   1. html::view-transition
   2. html::view-transition-root
      Proposed Resolution: html::view-transition

3. The pseudo-element which animates the size and position for tagged elements. Options are:

   1. html::view-transition-container(*)
   2. html::view-transition-group(*)
      Proposed Resolution: html::view-transition-group(*)

4. The pseudo-element which adds isolation for blending. Options are:

   1. html::view-transition-image-group(*)
   2. html::view-transition-pair(*)
   3. html::view-transition-effect-group(*)
   4. html::view-transition-images(*)
   5. html::view-transition-set(*)
   6. html::view-transition-image-set(*)
   7. html::view-transition-image-pair(*)

5. The pseudo-element which displays snapshot from the old DOM element. Options are:

   1. html::view-transition-old(*)
      Proposed Resolution: html::view-transition-old(*)

6. The pseudo-element which displays snapshot from the new DOM element. Options are:

   1. html::view-transition-new(*)
      Proposed Resolution: html::view-transition-new(*)

Please comment in case I missed an existing suggestion from #7788 or if you have any other suggestions.

• 1, 5 and 6 have only option which is the proposed resolution.
• 2 has a couple of options but I think we converged on (2.i) so I added that as the proposed resolution.
• 3, 4 need consensus.

Pasting fantasai's comment on 3,4:

• changing ::view-transition-image-group to ::view-transition-pair because it's shorter (and not a hyphenated phrase) and avoids evoking the idea of groups in SVG, which it's not conceptually similar to
• changing ::view-transition-container to ::view-transition-group because it's shorter and evokes the idea of groups in SVG (which create hierarchy in the graphic elements)

The downside of using "pair" is that it'll make it awkward if a future change needs a pseudo-element other than old/new under this element. It's not a pair anymore then. ^_^ But no hard preference there, we don't forsee anything that would add more pseudo-elements under this node right now.

I also didn't follow why the the element adding isolation isn't conceptually similar to SVG groups but the one which mirrors size/position of the DOM element is. @fantasai could you clarify?

Regarding shorter names, the motivation to use view-transition-image-group/view-transition-image-pair instead of view-transition-group/view-transition-pair would be that the latter sounds similar to view-transition-container. The "image" keyword there makes it obvious that it's a pair of replaced elements. We could go with view-transition-image-pair instead of view-transition-image-group.

[vmpstr]

Here's my 2c:

• Root: ::view-transition if fine, since adding root is unnecessarily verbose
• Container: Either container or group is ok with me, but I like the fact that group is shorter and easier to type, so that would be my vote
• Wrapper: I still think that we may need a qualifying word like image or effect in this name, since view-transition-set, for example, is too close to view-transition-group to not be confusing. pair is also a misnomer in some cases, since exit and enter animations would only have one constituent image. I like view-transition-image-set or view-transition-image-list, since set gives me an impression that order doesn't matter. So my vote is for view-transition-image-list.
• Old: view-transition-old is fine.
• New: view-transition-new is fine.

[fantasai]

I also didn't follow why the the element adding isolation isn't conceptually similar to SVG groups but the one which mirrors size/position of the DOM element is. @fantasai could you clarify?

In your extended proposal, this is the element that creates hierarchy, right? That's exactly what groups do in SVG.

my vote is for view-transition-image-list.

“list” has a very strong implication of “one or more, and probably many of an indeterminate number”, I think. Doesn't seem like a good fit for what is, afaict, only ever going to be two images (one of which might be empty)?

The downside of using "pair" is that it'll make it awkward if a future change needs a pseudo-element other than old/new under this element. It's not a pair anymore then. ^_^

Are you thinking there will be three images in some future revision? @_@

[khushalsagar]

In your extended proposal, this is the element that creates hierarchy, right? That's exactly what groups do in SVG.

By extended proposal I think you mean Nested transition containers. And yes, this will be the element which will have other container/group elements as children with that proposal.

Doesn't seem like a good fit for what is, afaict, only ever going to be two images (one of which might be empty)?

With the current API it can be 1 or 2 images. 1 in the case where a view-transition-name exists only on the old or new DOM. In that case the other replaced element is not generated. This is different from it being empty since no node (and box in the box tree) will be created for it.

Are you thinking there will be three images in some future revision? @_@

That comment was just to note a consideration for future flexibility. Given that we have no extension planned that could have more than 2 nodes, please disregard it. The only argument against pair (in the comments above) is that it's possible to have 1 replaced element under this element.

[fantasai]

The only argument against pair (in the comments above) is that it's possible to have 1 replaced element under this element.

I think that's fine. It's not an empty image but we're still conceptually transitioning between old and new, it's just that there's no image for one of these. :) Anyway that's my take.

[khushalsagar]

Thanks for the feedback @fantasai.

• I don't see any opposition to picking view-transition-group for the node which animations size and position. Since this element will have other view-transition-group elements as children (with nested transitions) it also builds off a similar concept in SVG. Added that as the proposed resolution in the first comment.

• For the pseudo-element adding isolation, I don't see any opposition to using the pattern view-transition-image-foo. Having the word image disambiguates it from view-transition-group since it can only have 1 or 2 replaced elements as children. The options for foo here are list, pair or set and ideal would be something which indicates that there can be 1 or 2 children

  • pair: Con is the case where there is guaranteed to be only 1 child (enter/exit animations).
  • set: Con is that set makes it sound like the order of children doesn't matter but it does. Also not clear that there can't be more than 2.
  • list: Again, not clear that there can't be more than 2.

  I'd be ok with pair or list. @astearns @tabatkins any other suggestions?

[css-meeting-bot]

The CSS Working Group just discussed css-view-transitions-1] CSS selector keywords., and agreed to the following:

• RESOLVED: Accept the proposed resolutions for items 1, 2, 3, 5, & 6

The full IRC log of that discussion

<dael> Topic: css-view-transitions-1] CSS selector keywords.
<dael> github: https://github.com//issues/7960
<fantasai> https://github.com//issues/7960
<dael> fantasai: This is about naming varios pseudo elements for view transitions. Proposal for almost all in the issue. Could probably resolve all except 4
<dael> astearns: Prop is take propsals for items 1, 2, 3, 5, 6 in the issue
<dael> astearns: Objections on those names?
<dael> RESOLVED: Accept the proposed resolutions for items 1, 2, 3, 5, & 6
<dael> fantasai: Item 4. view-transition-group we just accepted gives a grouping mech with a hierarchy. In item 4 it's a leaf with one or two images
<dael> fantasai: It exists because need isolation for blending. Item 4 is to name that almost leaf grouping. List of names is the proposed ones
<dael> fantasai: Names fall into two sets. Ones that include image, ones that have grouping word, and ones with both
<PaulG> q+
<dael> astearns: And this will not be used as much as rest?
<dael> fantasai: Yes
<astearns> ack PaulG
<dael> PaulG: Confirming these are pseudo element images snapshotted and will not hit ax tree or carry content?
<dael> fantasai: Right
<dael> PaulG: Thank you
<dael> astearns: we're at time. We'll come back to the issue for the one remaining thing

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-1] CSS selector keywords, and agreed to the following:

• RESOLVED: view-transition-image-pair

The full IRC log of that discussion

<fantasai> Topic: [css-view-transitions-1] CSS selector keywords
<fantasai> github: https://github.com//issues/7960
<fantasai> khush: This is about resolving on the selector keywords
<fantasai> khush: last meeting we got through everything except #4
<fantasai> khush: This is a pseudo-element for providing isolation for blending the old and new snapshots
<fantasai> khush: it's a leaf of the tree, only has old and new snapshots
<fantasai> khush: In terms of suggestions for naming, using word 'effect' or 'image', something to indicate that only nodes under here are replaced elements
<fantasai> khush: and need to disambiguate from view-transition-group() which cna change position/size, and can have other view-transition elements underneath it
<fantasai> khush: if we go with view-transition-image-foo, what's foo?
<fantasai> khush: Con of using "set" is that it doesn't indicate that DOM order matters, "list" makes it look like any number of elements but can only have two, and "pair" is nicest but sometimes there's only one element
<fantasai> khush: e.g. if DOM element only exists on one side
<fantasai> khush: but if we're okay with that, my proposal is view-transition-image-pair
<Rossen_> fantasai: +1 to using a pair. conceptually you have two things being transitioned independently
<Rossen_> ack fantasai
<fantasai> fantasai: wrt image, i'm less sure
<fantasai> JakeA: Tab wanted view-transition-images for brevity, but ppl didn't like plural
<fantasai> fantasai: for brevity, could also drop the "image" part and just say "view-transition-pair"
<fantasai> khush: "view-transition-group" and "view-transition-pair" not immediately obvious what's the difference
<fantasai> khush: but I could go either way, "view-transition-pair" vs "view-transition-image-pair"
<fantasai> Rossen_: I think group vs pair will clash for many non-native speakers, but wouldn't object
<fantasai> JakeA: It's not something folks will select a lot, ppl will select it ... I don't know, if they want to remove isolation for some reason?
<fantasai> Rossen_: even more reason to use a longer name
<flackr> Agree with Rossen_, I have a slight preference for view-transition-image-pair for clarity
<JakeA> +1 to image-pair
<khush> +1
<fantasai> Rossen_: Proposed to resolve on view-transition-image-pair
<fantasai> wfm
<lea> as a non-native speaker, I don't think group and pair are that frequently confused. Are there languages that do not distinguish between group and pair?
<ydaniv> +1 to image-pair
<fantasai> Rossen_: objections?
<fantasai> RESOLVED: view-transition-image-pair

[khushalsagar]

The spec already names this element as view-transition-image-pair so no edit needed.