Portals API


122 points | by ginkoid 156 days ago


  • tannhaeuser 156 days ago

    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 156 days ago

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

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

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

      • earthboundkid 156 days ago

        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 156 days ago


          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 156 days ago

            > 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 156 days ago

              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.

            • dane-pgp 156 days ago

              I see from the list of issues that "about:blank cannot host a portal"[0] (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?

              It would be really nice if the trick described in [1] could be combined with portals to allow a user to bookmark a fixed bundle of code for a web app, to defend against a malicious server sending different JavaScript on different visits or to different visitors.

              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?

              [0] https://github.com/WICG/portals/issues/214#issuecomment-6477...

              [1] https://news.ycombinator.com/item?id=17776456

            • rezonant 156 days ago

              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.

              • earthboundkid 156 days ago

                My uses case includes controlling both sides. I just don’t want to have to use JS for what is a non-interactive use case that could easily be handled declaratively by the browser.

                • rezonant 155 days ago

                  That's fair- I don't think there would be a problem with an X-Frame-Options header that specifically said frame extents can be made available to the embedder or something.

              • anoncareer0212 156 days ago
            • ocdtrekkie 156 days ago

              Portals was designed/built for AMP according to the official design document in the background section: https://docs.google.com/document/d/1ITizGVUmfFGktOOynHFhx87c...

              • madeofpalk 156 days ago

                They want AMP to be better - they trying to standardise the Google Search AMP experience into the spec and browsers so it’s better.

                • stingraycharles 156 days ago

                  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.

                • wizzwizz4 156 days ago

                  > This has already been shipped in Chrome (and Chrome only) for some time.

                  It's possible that this is a major selling point of the Portal element.

                • laurentb 156 days ago

                  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 [2] - https://www.youtube.com/watch?v=Z7qGHgF1Pb4

                • omneity 156 days ago

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


                  • oftenwrong 156 days ago

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

                    • Touche 156 days ago

                      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.

                      • oftenwrong 156 days ago

                        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.

                        • maxfurman 156 days ago

                          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 156 days ago

                            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 156 days ago

                              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.

                          • Cthulhu_ 156 days ago

                            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.

                            • oneweekwonder 156 days ago

                              > no need to rebuild your server-side rendered app to a single-page application.

                              server-side rendered html by its nature is also more accessible then spa/vdom frameworks, that tries to be fast by skipping the dom and re-implementing it in js(suckers).

                          • oftenwrong 156 days ago


                          • abrookewood 156 days ago

                            This does a much better job of explaining how these would work and why they might be useful.

                            • 236dev 156 days ago

                              I suspect that this will significantly cut down on the JavaScript needed to make websites feel more like a mobile app. I've had to add more complexity to the social network I'm building to make the web experience feel fluid. I'm also implementing a no-JavaScript subdomain of the website for people who hate bloat also.

                            • syberspace 156 days ago

                              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 155 days ago

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

                                • GhostVII 156 days ago

                                  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.

                                • dstaley 156 days ago

                                  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 156 days ago

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

                                  • Touche 156 days ago

                                    Good reason to dump support for Firefox imo.

                                    • Cthulhu_ 156 days ago

                                      Disagree; it's a draft proposal, they can weigh in and vote against it.

                                      If it's ratified and becomes a standard however, THEN they can start working on implementing it. But until then, nobody can slag off an implementer for not implementing a draft.

                                      • Touche 156 days ago

                                        What specific alternative is Mozilla proposing that solves the same use-cases that portals seek to solve?

                                        • kuschku 156 days ago

                                          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.

                                          • Touche 155 days ago

                                            So navigating from one page to another with an animation is not something that can be done in a secure way? Really? If so then the web really is dead.

                                            • kuschku 154 days ago

                                              Embedding one page in another is something that can not be done in a secure way in the general case.

                                              There are special cases where it is possible, but it's not possible in general.

                                  • jaffathecake 156 days ago

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

                                    • ilaksh 156 days ago

                                      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 156 days ago

                                        Found some context: 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...

                                        • voppe 156 days ago

                                          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)

                                          • hazz99 156 days ago

                                            You'll be able to implement more SPA-like instant navigation with preloading, etc.

                                            See the list of use cases [0] for more

                                            [0]: https://github.com/WICG/portals#use-cases

                                            • omneity 156 days ago

                                              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 156 days ago

                                                Why bother with that limitation?

                                          • ath92 156 days ago

                                            from the explainer [0]: 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.

                                            [0]: https://github.com/WICG/portals#readme

                                            • omneity 156 days ago

                                              The Portals API enables making multiple websites work together by allowing seamless handovers between each website, in a UNIXy way (each site does something narrow and specific).

                                              In short, the main thing Portals have over iframes is the ability to promote an iframe to become the top level website, and go back the other way around.

                                              You also get new APIs aiming at making the transition between two websites more seamless visually, and easier to integrate the functionality between the two.

                                              Check out the link I shared in the other comment for videos and further context.

                                              • elyobo 156 days ago

                                                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.

                                                • jasonlfunk 156 days ago

                                                  Why do we need a new spec for this though? It seems like these are just better iframes, why not just extend the iframe spec?

                                                • sradman 156 days ago

                                                  The link from szhu clarifies the purpose for me: Single Page App (SPA) like behavior via IFrame-like syntax.

                                                • mstade 156 days ago

                                                  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 156 days ago

                                                    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 . This is one noisy bit, so it shouldn't cause tracking concerns.

                                                  • osrec 156 days ago

                                                    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 156 days ago

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

                                                    • rafaelturk 156 days ago

                                                      Feels like <iframes>

                                                    • kevsim 156 days ago

                                                      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 156 days ago

                                                        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 156 days ago

                                                          > 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 156 days ago

                                                        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 156 days ago

                                                          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 155 days ago

                                                            Thank you for this clarification

                                                        • kkotak 156 days ago

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

                                                          • Tepix 156 days ago

                                                            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 156 days ago

                                                              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?

                                                            • Aeolun 156 days ago

                                                              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 155 days ago

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

                                                                • kowsheek 155 days ago

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

                                                                  • fernandotakai 156 days ago

                                                                    for some reason, that made me think of portlets.

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

                                                                    • dorcassmith 156 days ago

                                                                      English literature paper writing services have become very popular among english literature research paper writing service students seeking English Literature Writing Services and english literature essay writing services. https://researchpapers247.com/english-literature-writing-ser...