[css-view-transition-2] Should non-default view-transition-group act like contain?

[noamr]

Right now view-transition-group is a bit inconsistent, because:

• nearest and <custom-ident> refer to nesting from the descendant's point of view
• contain refers to nesting from the ancestor's point of view.

Perhaps it would make more sense that nearest and <custom-ident> would also act as contain? I think the discussion in the WG here was sort of saying it but the resolution was ambiguous.

If we do that, what happens when there's an invalid <custom-ident>?

cc @vmpstr @khushalsagar @fantasai, also @ydaniv that raised this concern in the last VT breakout.

[khushalsagar]

The reason we added contain was so not all children have to set view-transition-group for an example like this.

Can you expand on what you're proposing with "nearest and would also act as contain". I'm guessing <custom-indent> implies the parent specifying the list of children nesting to it. I feel like that defeats the purpose of having contain...

And not sure how nearest would be used if it's on the parent.

[noamr]

The reason we added contain was so not all children have to set view-transition-group for an example like this.

Can you expand on what you're proposing with "nearest and would also act as contain". I'm guessing <custom-indent> implies the parent specifying the list of children nesting to it. I feel like that defeats the purpose of having contain...

And not sure how nearest would be used if it's on the parent.

Let's say this is the hierarchy

html { view-transition-name: root }
  parent { view-transition-name: parent; view-transition-group: nearest; }
    child { view-transition-name: child; }

Based on the current spec wording, the view-transition-group for child would be root.
But there is some logic in having it be parent, as in, when an element becomes specifically nested, it also becomes nesting, and exiting the nearest group is the exception. In the last WG breakout @fantasai alluded to this being the essence of how this should work.

I wanted to either re-affirm the current spec wording (child would be not be nested in this example), or the other way (child would be nested in parent in this example).

[khushalsagar]

Based on the current spec wording, the view-transition-group for child would be root.

I thought child in this case would be under ::view-transition (no parent group). Since view-transition-group for child would be normal which is spec'd as: "The used value is the element’s nearest containing group name." There is no containing group name in the example above?

But there is some logic in having it be parent, as in, when an element becomes specifically nested, it also becomes nesting

Maybe we need a combo keyword, since in this situation you want parent to be nearest and contain at the same time? I don't know if there's precedence for this in CSS, defining which keywords can be combined with each other.

[noamr]

Based on the current spec wording, the view-transition-group for child would be root.

I thought child in this case would be under ::view-transition (no parent group). Since view-transition-group for child would be normal which is spec'd as: "The used value is the element’s nearest containing group name." There is no containing group name in the example above?

Oops, yes.

But there is some logic in having it be parent, as in, when an element becomes specifically nested, it also becomes nesting

Maybe we need a combo keyword, since in this situation you want parent to be nearest and contain at the same time? I don't know if there's precedence for this in CSS, defining which keywords can be combined with each other.

Yea, I think perhaps we should make it so that contain can be added to any of the other keywords. It would be more readable than the current situation where it's unclear whether a nearest/ident group is containing.

[noamr]

OK, I see 3 options here:

1. Keep the current wording
2. nearest and <custom-ident> implicitly also mean contain
3. contain can be added as a keyword to nearest and <custom-ident>, by default they don't contain.
4. Remove contain altogether, children should always reference their parent (or use nearest).

[ydaniv]

I still think it's somewhat confusing, plus there may be a scenario for an element to both a containing parent and a contained child.
I'm also not sure about the combo idea, since it also makes sense to have contain by itself.
Feels like it's either a case of a shorthand or two separate properties stuffed together into one, kind of where it started, right?

[noamr]

I still think it's somewhat confusing, plus there may be a scenario for an element to both a containing parent and a contained child.

I'm also not sure about the combo idea, since it also makes sense to have contain by itself.

We can still allow that, meaning normal contain

Feels like it's either a case of a shorthand or two separate properties stuffed together into one, kind of where it started, right?

I wonder if we need this contain keyword at all TBH. This kind of containment can be easily achieved through combinator selectors and perhaps it's better to keep it there rather than create this vt-specific mini-cascade.

[ydaniv]

Well, at the end of the day contain is mostly sugaring the other values. It's also possible to just remove it for starters.

[khushalsagar]

Out of the options in #10780 (comment), my preference would be 3). Not a fan of 2) since it makes it impossible to use nearest/custom-ident without also forcing contain.

[noamr]

Out of the options in #10780 (comment), my preference would be 3). Not a fan of 2) since it makes it impossible to use nearest/custom-ident without also forcing contain.

Also added option (4).

[fantasai]

This was the proposal we resolved on: #10334 (comment)

---

Just read though the thread (quickly, so might have missed something). I think what you want (?) is something like

view-transition-group: normal | <ident> | auto | contain where

• normal - defaults to placing directly under transition root (current behavior).
• <ident> - groups the under the element with the specified view-transition-name and automatically changes normal descendants to default to this item.
• auto or nearest - same as <ident> but chooses the closest ancestor with view-transition-name.
• contain - captures descendants to this element, but doesn't affect this element's position in the tree.

The property name hooks into the ::view-transition-group pseudo-element name, and it is not inherited. It applies to elements with view-transition-name only.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transition-2] Should non-default `view-transition-group` act like `contain`?, and agreed to the following:

• RESOLVED: all values other than 'normal' implicitly contain

The full IRC log of that discussion

<TabAtkins> astearns: elika was thinking this was alreayd resolved
<TabAtkins> fantasai: when we resolved to adopt the v-t-group, there was a proposal that covered this case, which describes the features exactly as specified here
<TabAtkins> noamr: I thought so, but figured it wasn't clear enough
<TabAtkins> fantasai: i'll drop a link to the proposal we adopted
<khush> q+
<TabAtkins> fantasai: the values in the proposal we resolved defined the values in the way noam is discussing here
<TabAtkins> noamr: yeah this detail was in the conversation, but not explicitly in the resolution
<astearns> ack khush
<TabAtkins> khush: the use-case that was raised in the issue, it wasn't clear how we resolved applied to it, let me understand
<TabAtkins> khush: right now v-t-group does two things, it parents to something, and says your subtree is parented to you
<vmpstr> q+
<fantasai> �the proposal as expressed in the issue
<TabAtkins> khush: you can't say both at the same time, so the proposal is to combine them and have them imply both?
<fantasai> https://github.com//issues/10334#issuecomment-2165649094
<TabAtkins> noamr: option 2, nearest and custom-ident implicitly mean contain too
<vmpstr> q-
<vmpstr> +1
<TabAtkins> fantasai: yes, that was in the description of the values
<TabAtkins> khush: i'm not a fan of it; i don't see why the nearest keyword has to implly it, rather than just allowing both keywords to be specified together if you want that
<astearns> q+ fantasai
<TabAtkins> khush: i think there are cases where you'd use nearest without implying you want your subtree too
<vmpstr> q+
<astearns> ack fantasai
<TabAtkins> fantasai: you could, but I think it's more likely you want capture.
<vmpstr> q-
<vmpstr> +1
<noamr> +1
<TabAtkins> fantasai: if you want to escape the capture you can use a name on the descendant; it doesn't *trap* them, it just contains by default
<flackr> +1
<TabAtkins> khush: ?
<TabAtkins> fantasai: if you come back with use-cases and decide that by default you don't want to capture, we could revisit, i just think by default it's the right behavior
<TabAtkins> khush: the thing that wasn't clear to me is that you could use a custom-ident on a descendant to escape, ok
<fantasai> https://github.com//issues/10334#issuecomment-2165649094
<noamr> nearest and <custom-ident> implicitly also mean contain
<fantasai> PROPOSED: all values other than normal implicitly contain
<TabAtkins> astearns: any objections to this proposal?
<TabAtkins> RESOLVED: all values other than 'normal' implicitly contain