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

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.

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.

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