3 ms·

https://github.com/WICG/portals/blob/master/README.md#use-cases https://github.com/WICG/portals/blob/master/README.md#use-ca... https://github.com/WICG/portals

https://github.com/WICG/portals/blob/master/README.md#use-cases https://github.com/WICG/portals/blob/master/README.md#use-ca... 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 6y 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 6y 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 6y 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-647716506 https://github.com/WICG/portals/issues/214#issuecomment-6477... [1] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456

ocdtrekkie 6y 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 6y 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 6y 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-647716506 https://github.com/WICG/portals/issues/214#issuecomment-6477... [1] https://news.ycombinator.com/item?id=17776456 https://news.ycombinator.com/item?id=17776456