[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).