Based on the proposed API in the README, you'd do this:

window.addEventListener('navigate', event => {
   // …
});

Would it be possible to move this to a worker to intercept or listen to navigation events, something like this?

self.addEventListener('fetch', function (event) {
  event.respondWithTransitionUntil(…);
});

Thoughts?

often leading developers to use large frameworks where they aren't needed

Reading through the README, I feel like this API is primarily targeting server-side rendered apps.
I have been using a transitions library to solve this very same issue.
I'm not sure what the big picture is.
Do you confirm that this new API wouldn't help for client side rendered apps?

You mention this API is interesting for managing scroll position across links:

Allow transitions to cater for a non-zero scroll position in the navigated-to page.

It would be nice to see an example here. (I'm guessing you'd be operating on document.scrollingElement.scrollTo.)

Using CSS we can create more complex animations, also the developers can create your own styles, or reuse styles created to your application.

There's a lot covered in https://html.spec.whatwg.org/multipage/browsers.html#nested-browsing-contexts. The spec language ought to just be clarified to ensure that the Transitions lifecycle and ownership models respect these rules.

EDIT: please ignore this. This was posted to this repo by mistake

This comment from a WICG forum post states that this proposal has received pushback Googlers. The objection stated is:

My proposal got push-back internally because it requires keeping both documents in memory at once for a bit.

Since I can't quite understand why this is a problem would you mind answering a few questions?

1. Can you expand on the objection if there is more information?
2. Do the objectors feel strongly that this is a "deal breaker" for this proposal?
3. If so, is there any work-around to the problem that you have thought of yet?

AFAIK, there is no way to tell whether a canvas is being drawn to (without monkey-patching the prototype of the interfaces). But it would be nice to be able to have a WebGL scene of a document transition to another scene's (primary) WebGL scene upon navigation. This could be done with the current proposed psuedocode, but I think some platform changes or special-casing may be required. Thoughts?

Looking at the example in the explainer, I was wondering if the spec should make any guarantees about how cheap calls to getBoundingClientRect() and similar are.

Transition/Animation code is going to need that kind of data by very nature, so it’d be good if calls like this would not force layout (unless style changes). Maybe even attach this kind of data to the event?

In Rendering, you state:

html { transform: translate(0, -20px); } on the top document will leave a 20 pixel gap at the bottom

What happens if you scroll?

After the result of transitionUntil resolves, is there any garbage collection that occurs of the outgoing page? Unless the spec explicitly nulls out all references to the outgoing document (and its descendants), I wonder if it's too easy to accidentally close-over some-or-all of the old document, preventing it from being GCed.

We could wait for the current transition (slow) or abort it somehow.

Let's say you've got a header and some other static parts on a page. Nowadays you'd fetch the new content with fetch and replace the relevant dom with the new content. Would it make sense to use 'navigate' and somehow only get some of the content you'd then embed on a certain place on the page, but still be able to go to that page regularly and get the whole document.

Can we give this ahead of time?

If we can give a number we should give it, but if we don't know it's going to be zero, we should provide that too.

I imagine in that event that some actors will implement some less-than-ideal transitions, users will expect the User Agent to intervene (or allow intervention) to disable Transitions. This sounds to me like non-normative text in the spec.

A few possible solutions or considerations that come to mind:

• There could be a browser-level flag to disable Transitions.
• A transitions permission type could be added to the Permissions API. By default, calling Permissions.query('transitions') could resolve {granted: true, permission: Permission {name: "transitions"}>}. No permission prompt would appear by default for documents, but the user would have the ability to disable Transitions on a case-by-case basis for a site/domain.
• There could be an algorithm for choosing whether a browsing context can trigger Transitions (à la the algorithm for browsing contexts that handles popups that obey the UA's popup blockers).
• In the case of causing user danger (not just annoyance), the Safe Browsing API (which is used by the browsers to prevent loading phishy, malware, dangerous sites) could be used to ban nefarious actors of Navigation Transitions. (I've been thinking about this for a while, so I'll file a separate issue about the possible attack vectors and mitigation.)

Shouldn't this just work the same way XML HTTP requests currently handles redirects? I.E. 'invisible' to JS?

You're probably aware, but IE 4 introduced this feature at a meta page level via filters. It might be worth looking at what filters were available and how they could possibly translate to a modern SPA https://msdn.microsoft.com/en-us/library/ms532847(v=vs.85).aspx#Interpage_Transition

I was wondering if and how this API could implement a static (and even functional!) headerbar/sidemenu throughout transitions like shown in this video (450KB). I’d like this API to be able to do this, but not sure if there’s any implications I am missing.

Taking some inspiration from the “Immediate Slide in/out transition” example, this is what I came up with:

window.addEventListener('navigate', event => {
  if (event.type == 'reload') return;

  const newURL = new URL(event.url);
  if (newURL.origin != location.origin) return;

  const oldContent = document.querySelector('#content');
  // Does some kind of animation so that the content div is not visible anymore
  const outAnimation = animateOut(oldContent);

  event.transitionUntil(async function() {
    await outAnimation;
    const newWin = await event.newWindow;
    const newContent = newWin.document.documentElement.querySelector('#content');
    // Styles that move content out-of-view so it can be animated in
    newContent.classList.add('about-to-be-animated-in');
    oldContent.parentNode.replaceChild(newContent, oldContent);
    return animateIn(newContent);
  }());
});

Would this work? Should this work?

@jakearchibald @paullewis WDYT?

As a developer, I may want to ensure that a transition begins only when either/or the originating document or destination document is visible to the user. Or, I may want to ensure the opposite: that a transition does occur. Using the Page Visibility API, I could check the visibility state of my document (document.visibilityState, document.hidden), but are there guarantees or assumptions I can make here about navigate firing?

Hola! Is there any update on this proposal? As in, is it making progress within the Chrome team? :)

Would love to see something of this sort become a reality!

You mention that whichever document has the highest z-index ends up in front. Does this mean each document is its own stacking context?

Put another way, can the elements in the documents be interleaved, or are they effectively siloed into their respective document's z spaces?