WICG/view-transitions

Naming clash with navigation API

jakearchibald opened this issue · 5 comments

jakearchibald commented

In the navigation API, "transition" means "a navigation that was intercepted as part of the navigate event and will result in a same-document navigation". This seems a bit tenuous to me. I think developers pretty strongly associate "transition" on the web to mean an animation of sorts, thanks to CSS transitions.

This seems like a pretty serious clash. Shared element transitions are visual transitions usually as part of a navigation, but the navigation API uses transition to mean something different.

However, @domenic said the naming process here was long and arduous, and didn't seem keen on renaming, so I'm not really sure what to do here. Some ideas just in case the navigation API naming could change:

  • canTransition -> canIntercept
  • navigation.transition -> navigation.ongoingIntercept
  • navigation.transitionWhile(promise) -> navigation.intercept(promise) or navigation.intercept(functionThatReturnsPromise) or navigation.interceptWhile(promise)

The navigation API will ship before shared element transitions.

jakearchibald commented

This seems to be where the 'transition' naming happened WICG/navigation-api#94 (comment)

domenic commented

In the navigation API, "transition" means "a navigation that was intercepted as part of the navigate event and will result in a same-document navigation". This seems a bit tenuous to me.

This is not how I would phrase it. I would phrase it as "a same-document navigation has just happened, but the page is still transitioning into the new state".

This seems like a pretty serious clash. Shared element transitions are visual transitions usually as part of a navigation, but the navigation API uses transition to mean something different.

I'm not sure I see the clash. At least for same-document navigations, they should have basically the same meaning. I guess shared element transitions also allow transitions for cross-document navigations, but that seems like an OK superset.

jakearchibald commented

I guess my worry is: canTransition will be false in cases where a transition might be possible, particularly if we get to cross origin transitions.

transitionWhile is something you'd call while doing an SPA navigation with a page transition, but the two transitions are different kinds of transitions.

Both features involve navigations, both features use "transition", but mean different things.

tigt commented

The next least-bad option might be animation from CSS?

I understand that CSS has a precedent for “transition” meaning auto-interpolation between two states, but from the looks of things this API will resemble animation-* more: #121, #134, #146. Considering animation is kind of a superset of CSS transition, I don’t think this is as much of a naming compromise as I thought when I started writing this comment.

(Other issues about naming: #122, #129. “Page transitions” was also the name for Internet Explorer’s old Page-Enter/Exit functionality, so maybe disambiguating further from that is all-upside.)