Portals API
wicg.github.io
wicg.github.io
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).
It's possible that this is a major selling point of the Portal element.
I realize this is a fairly cynical comment, but I don’t really see reason to be optimistic about all these developments.
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...
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.
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)
I love how the reason Google is pushing this spec is buried near the bottom.
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.
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...
Things like pym.js and iframe-resizer are probably the best bet security wise as it requires opt-in by the underlying page.
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
https://bugs.chromium.org/p/chromium/issues/detail?id=962500
They've already resulted in at least one same-origin policy bypass, lol.
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>.
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.
Of course there are techniques to improve page load time without turbolinks (using async script tags for example), but turbolinks predates many of those.
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).
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.
Why not just optimize page loading performace?
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.
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.
There are special cases where it is possible, but it's not possible in general.
Why are portals better than frames? How are they different? On the surface it seems like they must have similar functions.
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 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...
It seems to be some sort of in-page browser tab? Let's see what that brings. (besides interactive advertising, obviously)
See the list of use cases [0] for more
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.
- 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?
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.
Also does it play nice with all of the intelligent tracking prevention stuff Apple is implementing?
> 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.
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.
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).
It doesn’t look like this is it, wven though it shares the same name.
(and that thought made me shiver more than i expected)