[css-view-transitions-2] `view-transition-group` and tree-scoping

[noamr]

Follow up on #10334

It's unclear how to specify view-transition-group in terms of shadow trees. Sure, we can make the <<custom-ident>> a tree-scoped reference, which means it can't reference names from a different scope. However, what about nearest keyword etc? Keywords are not usually "tree-scoped".

Since view-transition-name is tree-scoped and view-transition-group doesn't make much sense in isolation from it, suggesting that both idents and keywords in view-transition-group are tree-scoped, and this property always resolves to none inside a shadow-tree.

//cc @khushalsagar @vmpstr

See also #10529

[khushalsagar]

+1 to tree scoping the property including the keywords. Basically group only applies if its computed value has the same tree scope as the name?

[khushalsagar]

Related issue for anchor positioning had the same resolution: https://github.com/w3c/csswg-drafts/issues/10526 and https://github.com/w3c/csswg-drafts/issues/10525.

this property always resolves to none inside a shadow-tree

I wouldn't quite say that, for scoped transitions inside a shadow tree this value can be not none. But it makes sense to treat the property as unset or initial value if its computed value's tree scope mismatches the tree scope of the transition. That's what we do with names as well right? If a name is using inner tree scope, we ignore it when the transition is started in outer tree scope.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] `view-transition-group` and tree-scoping, and agreed to the following:

• RESOLVED: v-t-group keywords are all "tree-scoped" in behavior

The full IRC log of that discussion

<astearns> ack fantasai
<Zakim> fantasai, you wanted to react to dbaron
<astearns> ack khush
<TabAtkins> khush: for the scoping one, we made a similar resolution for anchor positioning, wondering if we should be consistent
<TabAtkins> khush: not like we're saying each keyword is a specific tree-scope, it's more like the property is tree scoped
<TabAtkins> khush: if it's tree scope matches, the property applies, regardless fo the tree scope
<TabAtkins> khush: so should we just say that in general - if the property applies, it has to match the tree scope?
<astearns> ack fantasai
<TabAtkins> fantasai: I think it makes sense to be tree-scoped, dunno if we can come up with something generic, lots of palces we dont' want to be tree-scoped
<TabAtkins> fantasai: but for VT I think we should
<TabAtkins> noamr: as a general rule I think if the property describes a "style"...
<TabAtkins> fantasai: I think we'll still have to take that case-by-case
<TabAtkins> noamr: agreeing with you
<TabAtkins> +1 from me on one-offing this for now, don't generalize yet
<TabAtkins> noamr: proposed resolution, all vt-group keywords are tree-scoped in behavior
<TabAtkins> khush: can you give an example of what it means for 'nearest' to be tree-scoped or not?
<TabAtkins> noamr: if you use 'nearest' in a shadow, and the nearest vt container is outside the shadow, it won't match
<TabAtkins> RESOLVED: v-t-group keywords are all "tree-scoped" in behavior
<TabAtkins> githbu-bot, take up https://github.com/w3c/csswg-drafts/issues/10631