[css-view-transitions-2] MPA and SPA API compatibility

[jakearchibald]

I don't think there's anything to discuss here (please correct me if I'm wrong @astearns), so this is more a note to put something about this strategy in the spec, and remind ourselves of it as we develop the MPA API.

I think @zcorpan said it best:

we think it's important that the solution works well for MPAs and that it's consistent with the solution for SPAs. As such, if design changes are needed for the MPA use case that also affect SPA API, the latter should be updated as appropriate even though it has shipped

A concrete example: When I create offline-first web apps, I might use SPA for most navigations, but if I know there's a service worker update waiting, I might fall back to an MPA navigation, to pick up that update with minimal disruption to the user. It would be nice if the view transitions I define work seamlessly in both cases.

In practice, that means if we add high-level features for the MPA case, we should find a way to add them back into the SPA case, with as little extra work for the developer as possible.

We should be strict about this for full-document transitions (the type defined by css-view-transitions-1), although some may not make sense for future-features like scoped transitions.