
Portals API - ginkoid
https://wicg.github.io/portals/
======
tannhaeuser
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).

In principle I'm all for adding new declarative UI elements to HTML the markup
language but forgive me my lack of enthusiasm after years of failed attempts
by Firefox devs into this direction that were never implemented in Chrome. And
I can't see the point in HTML elements when you need JavaScript to make use of
them anyway (same issue with HTML components).

~~~
domenicd
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 [1] for mobile-only same-origin-only portals [2] 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 [3].

[1]: [https://github.com/GoogleChrome/OriginTrials/blob/gh-
pages/d...](https://github.com/GoogleChrome/OriginTrials/blob/gh-
pages/developer-guide.md)

[2]:
[https://developers.chrome.com/origintrials/#/view_trial/-768...](https://developers.chrome.com/origintrials/#/view_trial/-7680889164480380927)

[3]:
[https://github.com/WICG/portals/blob/master/README.md](https://github.com/WICG/portals/blob/master/README.md)

~~~
earthboundkid
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.

~~~
domenicd
[https://github.com/WICG/portals/blob/master/README.md#use-
ca...](https://github.com/WICG/portals/blob/master/README.md#use-cases)

[https://github.com/WICG/portals/blob/master/key-
scenarios.md](https://github.com/WICG/portals/blob/master/key-scenarios.md)
(although that's a bit out of date and some of the use cases mentioned there
might not be possible anymore as we've tightened the restrictions on cross-
site communication to prevent tracking)

~~~
ocdtrekkie
> So we anticipate many of the current cases for iframes, such as ads, being
> able to be replaced with portals.

I love how the reason Google is pushing this spec is buried near the bottom.

~~~
IMTDb
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.

------
laurentb
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 [1], 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 [2] or at least how
Google would want to have this as standard on the web...

[1] -
[https://news.ycombinator.com/item?id=23688857](https://news.ycombinator.com/item?id=23688857)
[2] -
[https://www.youtube.com/watch?v=Z7qGHgF1Pb4](https://www.youtube.com/watch?v=Z7qGHgF1Pb4)

~~~
lol768
> 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

[https://bugs.chromium.org/p/chromium/issues/detail?id=962500](https://bugs.chromium.org/p/chromium/issues/detail?id=962500)

They've already resulted in at least one same-origin policy bypass, lol.

~~~
domenicd
In code that was not shipping, note.

------
omneity
Here's some context on this with illustrations and videos:

[https://web.dev/hands-on-portals/](https://web.dev/hands-on-portals/)

~~~
oftenwrong
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](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>.

~~~
Touche
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.

~~~
maxfurman
It may or may not be faster in real terms, but it _feels_ faster to users,
because the browser window never blanks out between screens.

~~~
Touche
If you replace the entire body wouldn't there be a blanking that occurs
regardless? Or does the browser not repaint the parts of the page that look
the same in the before and after?

~~~
maxfurman
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.

------
syberspace
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?

Why not just optimize page loading performace?

~~~
satyrnein
In practice, that white screen is driving people to adopt client side
rendering and greatly increased complexity. Another option might be nice!

------
dstaley
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.

~~~
jameslk
I'd like to read more about Mozilla's decision. Where did you hear about this?

~~~
dstaley
[https://github.com/mozilla/standards-
positions/issues/157](https://github.com/mozilla/standards-
positions/issues/157)

~~~
zokier
Rendered view: [https://mozilla.github.io/standards-
positions/#portals](https://mozilla.github.io/standards-positions/#portals)

------
jaffathecake
The explainer is more up to date than the spec, and a better overview in
general
[https://github.com/WICG/portals#readme](https://github.com/WICG/portals#readme).

------
ilaksh
I feel like this would make the most sense presented in the context of frames.

Why are portals better than frames? How are they different? On the surface it
seems like they must have similar functions.

~~~
szhu
Found some context:
[https://github.com/WICG/portals](https://github.com/WICG/portals)

I think this proposal is a better starting point for readers than an API spec.

Goals, taken directly from the proposal:

\- Enable seamless navigations from a page showing a portal, to the portaled
page

\- Enable seamless navigations between pages of a portal-aware website

\- Avoid the characteristics of iframes which have negative impacts on
security, privacy, and performance

Also: [https://github.com/WICG/portals#summary-of-differences-
betwe...](https://github.com/WICG/portals#summary-of-differences-between-
portals-and-iframes)

~~~
voppe
Well damn, that is much more understandable and super interesting. Thank you!

It seems to be some sort of in-page browser tab? Let's see what that brings.
(besides _interactive advertising_ , obviously)

~~~
omneity
It's closer to Android Activities rather than tabs since you only have one you
can interact with at a time and you can send and receive data from it.

~~~
xwdv
Why bother with that limitation?

------
mstade
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?

~~~
domenicd
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.

Allowing hosts to inform the styling of portaled pages is a communications
channel, so we don't want to allow that directly (since it makes cross-site
tracking easier). That said, a page can tell via JavaScript (by testing
`window.portalHost`) whether it's being portaled, and we think it's probably a
good idea to extend this to CSS. See
[https://github.com/WICG/portals/issues/3](https://github.com/WICG/portals/issues/3)
. This is one noisy bit, so it shouldn't cause tracking concerns.

------
osrec
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?

------
coding123
Someone in the world has been trying soo soo hard to keep portals alive...
Which one of you did this.

~~~
chris_st
GLaDOS?

------
rafaelturk
Feels like <iframes>

~~~
domenicd
See [https://github.com/WICG/portals#summary-of-differences-
betwe...](https://github.com/WICG/portals#summary-of-differences-between-
portals-and-iframes)

------
kevsim
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?

~~~
politelemon
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.

~~~
kevsim
> Having had the pleasure of dealing with it for OAuth workflows, I'd remove
> the 'I', and just call it Safari's TP.

That's why I was asking :-) I've still got scars from making an in-house built
SSO for a major media company work across their sites when ITP launched, and
again when ITP 2 and 2.1 came out.

------
jameslk
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?

~~~
domenicd
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).

~~~
jameslk
Thank you for this clarification

------
kkotak
I use the delays between page loading to contemplate life. This will take that
way :(

------
Tepix
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.

------
chime
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?

~~~
domenicd
Yes and yes, although see
[https://news.ycombinator.com/item?id=23692160](https://news.ycombinator.com/item?id=23692160)
about the latter.

------
Aeolun
I need some way to pop out a functional part of my React DOM tree into another
window without fighting the browser.

It doesn’t look like this is it, wven though it shares the same name.

------
haolez
This could replace SPA in an elegant fashion, I believe. Pretty exciting!

------
kowsheek
Looks like Apple ripped off yet another Web spec... AppClips anyone?

------
fernandotakai
for some reason, that made me think of portlets.

(and that thought made me shiver more than i expected)

