This has already been shipped in Chrome (and Chrome only) for some time. Given Google is behind this, I have to wonder what their intent is with portal as I could see it end up in the next big round of attention and click hijacking a la AMP (think rich previews in Google Search giving visitors even less of a reason to go to your site).
Chrome team member here, and one of the people working on the portals spec.
This isn't accurate. This feature is being developed behind a flag, as it's still highly experimental and undergoing a lot of change. There is an origin trial  for mobile-only same-origin-only portals  which people can use to test how well this works in the wild, but it's nowhere near shipping.
You can learn more about the intention of the element in .
Can you give a motivating example for a website that isn’t Google to use portal? I’m not seeing it.
Something that I would actually use if it existed is an auto-height sizing iframe. Because that doesn’t exist, I have to hack around it with Pym.js. That would solve an actual need, unlike portal, which afaict only solves the “I want to be Google SER” usecase.
And the very first reason they state is to speed up loading by using hidden portals, and then activating them on demand.
When you first stated use case is a hack around what the spec really is supposed to provide, you have an issue.
If you want to speed up rendering of links, create a spec designed and optimised to speed up rendering of links. Not something that will clutter the DOM, then need additional CSS rules to hide what your new element is supposed to do altogether. All of that to sort of arrive to your primary use case.
I see from the list of issues that "about:blank cannot host a portal" (and in fact the parent page has to be served over HTTP/HTTPS). Does that mean that it's impossible to have a bookmarklet with a data URI that defines a page with a portal in it?
This would probably also require that the SRI spec be extended to work with portals, so that the contents of a portal could be guaranteed to match a specified hash. Are there any plans for that?
Unfortunately auto resizing iframe without the opt-in of the embedded page could be used to snoop on private data using frame extents as a side channel. Imagine a page that is 10 times longer if you are signed into it-- a third party site you visit could use this fact to determine if you are signed into the embedded website, for instance, and they could make the frame invisible and you wouldn't even know it happened. While the embedding site can of course opt out of iframe embedding with X-Frame-Options, we can't assume that sites are built that way, and there may be legitimate use cases for iframing where you still don't want to expose the size of the underlying page.
Things like pym.js and iframe-resizer are probably the best bet security wise as it requires opt-in by the underlying page.
The fundamental idea of AMP is simply not something I can get behind, unless it doesn’t involve hosting the webpages elsewhere (i.e. no more amp.google.com). From the looks of it, though, it seems like they don’t necessarily want AMP to be better, they just want AMP to be more popular. That way they can always point at more broader use cases and don’t look as evil.
I realize this is a fairly cynical comment, but I don’t really see reason to be optimistic about all these developments.
My "non-professional in the field" opinion of this at first glance is that this seems like a concept ripe for abuse and security holes (not to mention scam potential) trying to be a successor to something that was already pretty bad in that regard...
This would be better if it was designed with the end user in mind from the get go and in full control of defining portals himself. (and by that I mean, if you take the example linked by omneity , I should be the one defining which "shopping cart" i'm sending the recipe ingredients to or which social app is triggered and what data am I sending it).
For some reason this also gives me some "Fuschia OS" vibes  or at least how Google would want to have this as standard on the web...
It appears that the motivation behind the concept of portals was to eliminate perceptively slow page transitions, and allow a developer to create a multi-page experience that behaves like a single-page app.
Given this motivation, portals are a single solution to two problems. In my mind, it would make more sense to divide the concept, and create two separate, complementary features:
1. A way to eliminate perceptively slow page transitions, perhaps with an approach like turbolinks: https://github.com/turbolinks/turbolinks . Require minimal changes to existing markup, and allow <a> to use the new, more-seamless page transitions.
2. A new UI element that is like a modern take on the iframe: the <portal>.
I'm trying to understand how Turbolinks makes things faster. What I'm gathering is that it's the merging of <head> that helps. Because if you have stylesheets or scripts in your head that have already ran using Turbolinks will prevent refetching and rerunning those things.
The downside to the approach is that it cannot stream the HTML response, which is what browsers do, so you wait longer for the page to complete. But if you have a fast enough server then the gains from not rerunning scripts probably helps more.
I believe you are correct about that aspect of turbolinks.
However, what I was alluding to in my comment was the background-load-and-swap approach used by turbolinks. An <a> could be enhanced to load the next page in the background, and then swap in the content. When combined with smart pre-fetching and pre-rendering, this will yield page boundaries that feel seamless.
Note that this is exactly how portals will make browsing feel faster. My abstract proposal is merely to make this a more general feature that can enhance plain links, rather than coupling it to a new UI element.
A regular page load will block and show a blank screen until all of the style tags, script tags, etc. have been fetched. Replacing the body does take a few ms to paint, but does not need to wait on any other fetches.
Of course there are techniques to improve page load time without turbolinks (using async script tags for example), but turbolinks predates many of those.
Yeah IIRC (from when it was introduced) it's an easy way to add SPA-like performance to your Ruby app by only re-rendering the <body> tag; no need to rebuild your server-side rendered app to a single-page application.
So the tradeoff we're making is between the user seeing a white screen for a couple of (mili)seconds and the websites getting even more bloated by preloading content that the user might or might not want to see in the future?
I think it makes a lot of sense in cases where you have multiple lightweight webpages (ex. Wikipedia). The extra bloat is minimal and you still get the benefit of smoother and faster transitions between articles. Presumably the preloaded content would be loaded in the background so page load wouldn't be affected, I don't really see the downside to this aside from data/battery usage if you are on mobile.
Just a heads up that the WebKit team hasn't weighed in, and Mozilla does not intend to look at this specification at all in the near future. So this looks like another Chromium-only feature for the time being.
Not every use case can be supported in a safe and secure way.
Just like "update the firmware of attached USB MIDI devices via the web, without a permission popup" was something Chrome implemented, and after quite some time had to realize this might not be the best solution.
Sometimes you just have to stop and think if this is really the best tool for the job, or if you should use something else instead.
from the explainer :
Portals enable seamless navigations between pages. In particular, we propose a new <portal> HTML element which enables a page to show another page as an inset, and then activate it to perform a seamless transition to a new state, where the formerly-inset page becomes the top-level document.
Portals encompass some of the use cases that iframes currently do, but with better security, privacy, and ergonomics properties. And via the activation operation, they enable new use cases like preloading or navigation transitions.
I feel like this would make the most sense if it was presented with any context at all. Reading a low level and detailed spec is much easier if you have some higher level understanding of what they're talking about at all.
Looks cool. Some random thoughts that may or may not be of any use to anyone:
- It looks like postMessage is the communications channel to use between host and portals and vice versa, which makes sense to me.
– Looks like it'd be trivial to use portals to create an SPA-like experience without having to give up on multiple independent pages. The SPA-part would be aggregator pages that use postMessage to communicate and coordinate, but it's unclear what the performance implications of this would be. Are portals meant to be lighter weight than iframes or are they entirely new browsing contexts and therefore just as heavy?
- Can hosts inform the styling of portal pages, beyond the portal page recognizing that it has a host and therefore switching style sheets? I guess you could do this with postMessage, but I mean are there plans to formalize styling and style boundaries in some way, perhaps not unlike web components?
Note that postMessage is only allowed same-origin, for privacy reasons (to avoid cross-site tracking).
Portals are entirely new browsing contexts, so just as "heavy" as iframes. Iframes are generally not that heavy though (especially compared to modern JS frameworks); I'd encourage you to experiment to see how well portals might work for your use cases.
Is the window context separate for portals? And can we potentially inject some data into a portal, so that we could use them to safely load plugins in a web app, while only giving them a certain level of control on an apps state?
Can we use Portals to implement something like single sign on without either needing to redirect to an identity provider or doing a pop up? These things are increasingly hard to pull of without redirects/popups in a modern browsing world that is hostile to 3rd party cookies (which is mostly a good thing).
Also does it play nice with all of the intelligent tracking prevention stuff Apple is implementing?
You can think of this as an inline popup that can expand to take over the page, so a somewhat seamless redirect. But it doesn't do away with what you're asking about; the redirect needs to happen, or a popup needs to happen. Portals can't be interacted with in the way iframes can, so OAuth worfklows will require going from your site to OAuth provider back to your site.
> Also does it play nice with all of the intelligent tracking prevention stuff Apple is implementing?
Having had the pleasure of dealing with it for OAuth workflows, I'd remove the 'I', and just call it Safari's TP.
A few questions I have: what happens to the host page when a portal becomes the active page? Does the host page continue to run in the background? If so, what happens when you open multiple portals? I assume the predecessor host pages must stop running otherwise we run into a memory leak type of scenario?
The current specification allows the portaled page to optionally "adopt its predecessor", putting it into a portal.
It's not clear whether this functionality will fully survive, as we refocus portals around a more tightly scoped prerendering-focused MVP. For example predecessor adoption might only happen automatically (via the browser's already-existing back-forward cache), instead of via an explicit JS API. We'll see.
Multiple portals are generally like multiple iframes, although we may also impose some restrictions on "backgrounded" portals (e.g. the automatic predecessor-adoption-into-the-bfcache mentioned above).
This could be interesting if used in conjunction with 360° virtual walkthroughs. Instead of having buttons or icons that indicate links between 360° images you'd see a portal in the shape of a small sphere.
Do the pages initially shown in portal run JS normally and preserve state when promoted to main? Does the previous main page preserve JS state when demoted to portal and then repromoted from portal to main?