[Proof of concept] Portals API + Navigation block

[michalczaplinski]

Portals API

The WICG Portals proposal aims to create an API for enabling seamless navigations between sites or pages. One of the use cases is enabling seamless navigations in multi-page applications (like WordPress) enabling the kind of user experience currently reserved for single page applications built with Next.js, Frontity and the like.

⚠️ The proposed Portals API is currently only available in Google Chrome behind a flag, you can enable it in chrome://flags/#enable-portals

The document proposes adding a <portal> element to to HTML, which would would have a functionality similar to <iframe> and <link> combined. The key difference from an iframe being that the <portal> element would have a portal.activate() method which when called would seamlessly navigate to the page that was rendered in the portal.

Another way of conceptualizing portals would be as a way to safely prerender/preload content. There have been previous attempts at standardizing a similar functionality via <link rel="prerender"> but it does not actually prerender content as currently implemented in major browsers.

At the same time, the support for "high-level navigation patterns" is not planned to be included in the Portals API. To quote from the explainer:

Portals provide a low-level building block for prerendering with preview, which can be combined with the usual tools of HTML for creating navigation pattern UIs. Portals offer the best of both worlds: the low complexity of an MPA with the seamless transitions of an SPA. Think of them like an <iframe> in that they allow for embedding, but unlike an <iframe>, they also come with features to navigate to their content.

There are many more details included in the explainer which I would encourage you to read because it both explains the objectives and use cases as well as detail other considerations like Security and Accessibility.

This PR

This PR is a simple integration of the Portals API into the Navigation block. The script will preload all pages that a user has added to the Navigation block. For now it is not much more than a proof of concept for how we might want to use the Portals API in the future.

How to see it in action

• Use an FSE theme like TT1 blocks
• Create a couple of pages
• Add a Navigation block to the header of the site and add at least 2 links to pages to the block.
• Open your site and click on the links in the Navigation block, you will notice that the pages load instantly 😮 (like in a Frontity or Next.js SPA)

Some Concerns

Loading multiple portals

After having played around with the API in this PR, I notice that there is no ability to re-use portal elements across different pages. For example, you are on a /products page and the Navigation block has created some portals to other pages. You navigate to another page via a portal, let's say a /blog page. Now, the Navigation block on the /blog page has to re-create the same portals to other pages again!

I have explained this in more details in WICG/portals#276

This is somewhat wasteful and would make it hard to create a user experience on par with that offered by SPAs today.

Accessibility

There are some ongoing discussion as to whether the <portal>s should be exposed as links or buttons.

Also currently, portals cannot be opened in a new tab in the same way that links do.

Browser support

Currently, only Chrome has implemented a version of this Portals proposal and other browsers have so far postponed even declaring an intent to implement it (Firefox) or have not even acknowledged it officially (Safari, others) https://github.com/WICG/portals#stakeholder-feedback