[css-view-transitions-2] Retaining `view-transition-class` (and `view-transition-group`) from old state

[noamr]

When resolving view-transition-class, the rule is "last capture wins". That means that as long a view-transition has a new state, the old class is discarded.

However, there are legit use-cases for retaining the "old" class without having to explicitly specifying it again. For example, if the author uses an ordinary class in-viewport to ascertain that a certain element intersects with the viewport, they should be able to use the following to customize the animation:

.element.in-viewport {
  view-transition-class: fly;
}

.element:not(.in-viewport) {
  view-transition-class: fade;
}

With the current "last capture wins" rule, the fade-only rule would only apply when the element flys out, and it's impossible to use view-transition-class to make it fade also when flying in, because .in-viewport would be true in the new state.

Proposing to have a function that applies to view-transition-class, and can be applied to view-transition-group if we use the same rule in #10631, that copies the value from the old state.

e.g.:

view-transition-class: from-old() new-class-1 new-class2;

There is probably a better name for this, but the general idea is that a particular function "copies over" the names from the old state, and that this is specific to view-transitions rather than a generic merge primitive.

/cc @khushalsagar @vmpstr @nt1m @fantasai

[nt1m]

A function is an odd choice in this case IMO.

Maybe: view-transition-class: preserve-old / new-class-1 new-class-2;

I have a feeling @fantasai would have good ideas on how to make the syntax more CSS like.

[noamr]

A function is an odd choice in this case IMO.

It reads like something from the platform rather than a custom ident. But whatever we end up with is fine with me!

[fantasai]

Why not include the old state's classes by default? Is there a use case for dropping them? Is that use case more common than the use case for keeping them?

[nt1m]

It's just more logical to drop the old classes by default, since we're reading from the view-transition-class property directly.

[noamr]

Why not include the old state's classes by default? Is there a use case for dropping them? Is that use case more common than the use case for keeping them?

For example, a view-transition-class might depend on some state (:focus-within?) and if that state changes when capturing the new vt state we'd want to drop that class.

I don't think either is more common than the other, they're both legit but we chose this one (in the WG discussion) because it's simpler and more consistent with the rest of CSS. I believe that if we changed the default we'll have the inverse problem of some opt-in to override/omit the old classes.