[css-view-transitions-2] Reflecting view-transition-group in computed style

[noamr]

Folllow up on #10334

We defined a few rules on how view-transition-group is computed:

• A few keywords (nearest/normal/contain)
• Some rules that define whether a group is valid (e.g. has to refer to an ancestor view-transition-name)

We have all the information we need during style computation to compute a resolved view-transition-group, so hypothetically
getComputedStyle can already return the resolved group. It fits with other things that getComputedStyle does (colors, length, transforms etc). The other option is to resolve them when capturing

There are a few options:

1. Style computation just passes things along to the view transition engine, reflecting the keywords and everything to getComputedStyle
2. Style computation resolves the nearest/normal/contain keywords, but doesn't resolve rules that depend on the existence of view-transition-name.
3. Style computation resolves everything and view-transition-group is always computed to be a valid ancestor view-transition-name.

I think (3) would be the most useful for developers and consistent with other things getComputedStyle does, but perhaps the overhead on style computation is unnecessary.

[khushalsagar]

I lean towards (1) because it'll allow us more room to iterate on whether a name applies or not going forward.

For example, on #8282 we considered a CSS property which says, "ignore the name if it's offscreen". If we went with (2) or (3) then we'd have a harder time doing this since we'll need to know if an element is offscreen during the style cascade which would be extremely complicated. Or we'd have to say the computed style gets you the final name except in these cases which is also confusing.

[vmpstr]

I think the overhead here is worth considering. The problem is that if done at style computation, then this needs to be kept up to date with things like topology changes and style invalidations all the time. However, this properly only has an effect when a view transition starts which is a rare event compared to style computation.

My preference would be to have the computed value be the specified value, and then figure out the used value at capture time (or whenever the transition actually begins)

[noamr]

I lean towards (1) because it'll allow us more room to iterate on whether a name applies or not going forward.

For example, on #8282 we considered a CSS property which says, "ignore the name if it's offscreen". If we went with (2) or (3) then we'd have a harder time doing this since we'll need to know if an element is offscreen during the style cascade which would be extremely complicated. Or we'd have to say the computed style gets you the final name except in these cases which is also confusing.

I don't think this is a sufficient argument. If we come up with a use case that can't be resolved during style computation in the future, we can handle it then.

I think the overhead here is worth considering. The problem is that if done at style computation, then this needs to be kept up to date with things like topology changes and style invalidations all the time. However, this properly only has an effect when a view transition starts which is a rare event compared to style computation.

Optimizations for this are possible, such as only computing it when calling getComputedStyle or startViewTransition.
I don't think it should be a blocker.

I do agree that there is some implementation complexity to it and we should weigh whether the slight ergonomic benefit is worth it.

[nt1m]

My preference would be to have the computed value be the specified value, and then figure out the used value at capture time (or whenever the transition actually begins)

Same, for the reasons stated above. I don't think unnecessary complexity should be introduced if there's no significant benefit.

[noamr]

Closing this for now, I don't think anyone proposes something different from the existing text.