[css-view-transitions-2] Behavior of mismatching types between old and new document

[noamr]

As per #9523, both documents can specify "types" for the cross document view-transition, which affects the :active-view-transition selector.
Note that these types apply both at the old and new document, as they can affect (for example) which elements are captured.

When capturing the old document, only types specified on that document can apply.
On the new document, we can do one of the following:

1. apply only types specified in the new document (override)
2. apply both the types in the old and new documents (union)
3. apply only the types that are in both documents (intersection)
4. fail the transition if the types don't match

The current PR specified (1), the advantage being that it's the most flexible and least opinionated - if developers want to have different types in both documents they can do it, and if they want them to be strictly the same they can restrict it themselves, there is no technical reason to have this restriction or to force a union.

There are also advantages to the other approaches, perhaps mandating the same types would lead to design that is less error-prone.

[khushalsagar]

Discussion summary for the different options:

1. apply only types specified in the new document (override)
   This option is easiest to reason about, the type is a document-scoped property. So new Document gets the type in its declaration only. It would also work if the transition type depends on parameters the new Document is aware of: navigation type and from URL.

2. apply both the types in the old and new documents (union)
   This option helps with use-cases where the from URL is not enough to define the transition type. For example, a different transition happens if the user scrolls to a particular element or interacts with the page. We could use some use-cases to understand how common this is. There are ways to polyfill this in script (examples below) so this option would be a more declarative way to do something feasible in script:

   • Send info about the old Document's state to the new Document via other APIs. For example, Expose information about last activation/cross-document navigation whatwg/html#9760 will provide a reference to the last navigation entry on the new Document which has getState() for arbitrary information. Though that won't work for location.replace cases where the from navigation entry is not preserved. @jakearchibald did you say there's a workaround for this?

   • Can also be done with session storage.

3. apply only the types that are in both documents (intersection)
   The downside of this option is that the old Document needs to add a type for all possible states the new Document could be served in. And this might be dependent on state on the server.

4. fail the transition if the types don't match
   Same con as above. There is a legit use-case here to use types to detect a change in website version (if a deployment happened before the transition starts). But seems better to use an explicit "version" descriptor for it.

[vmpstr]

@ydaniv @jakearchibald @bramus for thoughts on what is preferable here from a developer perspective

[bokand]

I'll add my thoughts with the disclaimer that I'm just now trying to catch up on earlier discussion and might have missed some discussion or use cases.

My interpretation of type is that it tags a transition (e.g. type StreamToItem), rather than a page, so it doesn't really make sense to me that B would be setting a type since the transition is already created. i.e. the author already has all the context necessary on A (they know: A, A's state, and B) and A has been captured with the given type which B cannot change.

So there's an additional option to consider:

5. Apply only the type specified in the old document: @view-transition { type: foo } on a page A applies the type foo both on the outgoing and incoming pages but only for transitions initiated from page A; It isn't applied to transitions where A is the incoming page.

This means authors don't have to do from-URL matching to deduce an incoming type and also corresponds to the SPA startViewTransition model where the type is specified only on initiation.

However, I've since seen this comment rebutting this. i.e. B can have transition-affecting state that A may not know about (e.g. cache hit vs. loading page).

If that is a legit use case then I feel like it's a point in favor of option 2 (union). In that case, you still get the benefit of the above model where A defines the transition type which is usable on B, but B can override it, assuming additional types add specificity:

/* On page B */
@view-transition {
  navigation: auto;
  type: LoadingPage
}

html:active-view-transition(StreamToItem) ::view-transition-group(item) { /* Animate In */ } 
html:active-view-transition(NotificationsToItem) ::view-transition-group(item) { /* Animate In Differently */ }

/* On loading page and don't have an item yet so do something else.
   Applies because additional parameters add specificity */
html:active-view-transition(StreamToItem,LoadingPage) ::view-transition-group(item),
html:active-view-transition(NotificationsToItem,LoadingPage) ::view-transition-group(item) { ... }

[khushalsagar]

Those are excellent points @bokand! Another use-case to allow the new Document to specify types is render-blocking. The old Document doesn't know how much of the new Document will be fetched before the browser stops render-blocking. So letting the new Document add/specify types allows it to dynamically pick a fallback transition.

My preference would be option 1 or 2. Not leaning strongly on either of them. If we go with option 1 (only types from the new Document), authors can easily still do option 2 (union) by using NavigationHistoryEntry's getState API.

---

Btw, we might need to solve the use-case you mentioned (if it turns out to be common) regardless of this issue:

However, I've since seen #8960. rebutting this. i.e. B can have transition-affecting state that A may not know about (e.g. cache hit vs. loading page).

If the UI on the new Document is going to be different based on whether there's a cache hit, that could influence which elements on the old Document have a view-transition-name. Navigation API could help here: we could expose a bit indicating the Document is cached or not for same-origin pages; or allow the Document to update state stored on its NavigationHistoryEntry when its being evicted.

[vmpstr]

[...] i.e. B can have transition-affecting state that A may not know about [...]

[...] The old Document doesn't know how much of the new Document will be fetched [...]

Both of these say that a new document can have some state that the old document isn't aware of and doesn't need to be aware of. My argument for option 1 vs option 2 is the same: the old document may also have some state or configuration that the new document doesn't need to be aware of, but making types necessarily exposed from old document to the new has a potential of making this awkward.

My interpretation of type is that it tags a transition (e.g. type StreamToItem)

I fully agree with this interpretation. However, I think each page should be naming its incoming and outgoing transitions. This is consistent with option 1, where the old page names its outgoing transition something like "foo". The new page matches the transition based on URL and navigation type, and names this (incoming) transition. It should absolutely feel free to name it "foo" as well, or "bar" or whatever else.

The fundamental difference here is whether we want types to be a source of information passing from the old page to the new. If we don't care about this channel of information, then option 1 isolates both pages better making type name selection namespaced to the page. If we do want the type to send information from the old page to the new, which would be the case if there are cases where the old page can navigate to a new page in "different" ways, meaning different types but all else is the same, then we should obviously go with option 2.

As an aside, there's another issue with option 2: it limits what names the new page can use for its types by some unknown set that the old page can specify. For example, if the new page has types "foo", "bar", and "baz" set up for its internal transitions, then it has to be careful that the set of these names doesn't appear in the set of names that the old page can specify during a transition, since that would inadvertently apply styles that were not meant for the incoming transition.

[khushalsagar]

My argument for option 1 vs option 2 is the same: the old document may also have some state or configuration that the new document doesn't need to be aware of

It feels like this doesn't align with David's point, "My interpretation of type is that it tags a transition (e.g. type StreamToItem), rather than a page" but does sound reasonable. Can you think of an example?

The fundamental difference here is whether we want types to be a source of information passing from the old page to the new.

I like this line of reasoning. I'm convinced that transitions need information passing between the 2 Documents, but "type" doesn't need to be how that happens. Other APIs (like session storage or navigation) already provide a generic way to do this. And we can add a "oldTypes" attribute to the reveal event (or ViewTransition object) if it turns out that type is indeed a preferred way of passing transition related info to the new Document. So at least the default would be option 1 but authors will be able to get option 2 with trivial script.

I missed responding to this, "also corresponds to the SPA startViewTransition model where the type is specified only on initiation". The difference between SPA/MPA is that with SPA authors can initiate the transition once all relevant info about the new state is known. But that's not always possible with MPA. So the model for setting types needs to diverge here.

[vmpstr]

Can you think of an example?

I'm not sure what example you mean. The old page can have any number of states, like say expanded details vs collapsed details, and depending on the state of collapse the VT hero image will come from either "details-collapsed-transition" type or "details-expanded-transition" type. That's not something the new page cares about, it just needs to know there's a hero image

[khushalsagar]

like say expanded details vs collapsed details, and depending on the state of collapse the VT hero image will come from either "details-collapsed-transition" type or "details-expanded-transition" type

Thanks, that's the kind of example I was looking for. Where 2 different transition types on the old Document map to the same transition type on the new Document. In this case the set of elements with a view-transition-name and the CSS for the animation on the new Document will be the same irrespective of which element provides the hero image.

[bokand]

The fundamental difference here is whether we want types to be a source of information passing from the old page to the new. If we don't care about this channel of information

+1. I was thinking that type would be how incoming and outgoing pages sync up on their states and coordinate on matching transition styles but as long as the alternatives are ergonomic then I now agree it doesn't make sense to have the types between documents interact.

authors can easily still do option 2 (union) by using NavigationHistoryEntry's getState API.

Hmm, since there's no Javascript API, are you thinking authors will use CSSOM to insert the appropriate @view-transition (or modify an existing) rule? I suspect this might be non-trivial in complex cases given they might have to pick out the correct one manually. Maybe we need a better way to do this? (or maybe I'm missing an existing option)

additional tangential replies

The difference between SPA/MPA is that with SPA authors can initiate the transition once all relevant info about the new state is known. But that's not always possible with MPA. So the model for setting types needs to diverge here.

Right, forgot the fetch can (and should) happen before calling startViewTransition, rather than inside of it.

As an aside, there's another issue with option 2: it limits what names the new page can use for its types by some unknown set that the old page can specify.

It seems like authors will already have to do a fair bit of coordination between pages since they'll have to make sure view-transition-names are coordinated between pages (and don't clash with internal state transitions), but point taken.

[khushalsagar]

Hmm, since there's no Javascript API, are you thinking authors will use CSSOM to insert the appropriate @view-transition (or modify an existing) rule? I suspect this might be non-trivial in complex cases given they might have to pick out the correct one manually.

Good point. That's what I was thinking but didn't realize the clunkiness of using CSSOM. One idea based on a couple of related issues: #9542 and #9595. Add a couple of attributes to the ViewTransition IDL and keep the timing for parsing the CSS opt-in here as-is.

interface ViewTransition {
  readonly attribute oldTypes;
  attribute types;
};

• Before dispatching the reveal event, browser parses the opt-in rule to get the declarative types. oldTypes is types from the old Document. types is from the new Document and the list which is currently being applied.
• In the reveal event, the developer can overwrite types to whatever value they want. So by default (and with no script) you get option 1. But authors can trivially use oldTypes and types to implement option 2, 3 or 4.
• In the SPA case, oldTypes and types will start off with the same value but authors can similarly overwrite types whenever needed.

[vmpstr]

Keeping this in CSS, would that be equivalent to types overriding (option 1) with a media-like query that is able to target old types?

• In the SPA case, oldTypes and types will start off with the same value but authors can similarly overwrite types whenever needed.

I don't know if I like that. For MPA, it feels like the reveal event changing types would be "configuring a transition". I would prefer that after transition starts (for some definition of start), we don't update types. This simplifies spec and the mental model that types name the transition, rather than be dynamic types that can change at any time

[noamr]

Keeping #9542 in mind, I think that (1) still makes the most sense to me, and also it's the simplest in the sense that types don't transfer across documents.

Yes, types apply to the transition, but who said that they need to stay the same throughout the whole transition? They apply to the transition at a given moment. This would also be a solution for #9424 - in MPA we'd have different types in the two documents, and ichanging viewTransition.typeList in JS would be the equivalent.

The problem that I have with anything that takes the old document into account in the new document (which is 2-5) in the new document is that it's unnecessarily opinionated about what types mean. Why not let the authors do that themselves? if they want to apply any kind of restrictions they can do it themselves based on their content rather than mandating this in the platform.