[View Transition] [Navigation API] Allow opt-in for cross-document navigations via `navigate` about html HOT 1 CLOSED

We discussed this internally today and decided to abandon this in favour of the pageconceal idea on #9702. The summary is as follows:

• The use-cases on #9702 will still remain since fundamentally navigate is at the beginning of the navigation lifecycle and pageconceal will be at the end (right before commit). Both the opt-in and customization can depend on information known at commit time.

• A pro of letting authors provide the opt-in via navigate, instead of pageconceal, is performance. The API contract for pageconceal will be as follows:

  • If there is a ViewTransition, it blocks the new Document from painting (pagereveal must fire after pageconceal). So pageconceal delays the navigation from committing.

  • If there is no ViewTransition, then committing the new Document can be done in parallel with hiding/unloading of the old Document.

  This means knowing whether there is a VT opt-in in navigate avoids making pageconceal blocking. But having the opt-in on navigate makes another planned extension for the CSS opt-in complicated:

  @view-transition {
    navigation: auto;
    to: urlpattern(...);
  }

  We'd like the to value here to apply to the final URL (after all redirects). If the author's CSS has an opt-in for a to value and script does an opt-out in navigate, which one wins? And if the author does an opt-in via navigate but the CSS has an opt-out, does that still apply?

  We considered making to here correspond to the initial URL (instead of final URL), authors could handle the final URL scenarios in script. But it came up that same-origin redirects is a common enough use-case (for example with form submission or redirecting to the login screen) that keeping them declarative is nicer.

Closing this issue to continue the discussion on #9702. Please re-open if I incorrectly assumed anything.

from html.