4 ms·

In what way loading a site on a portal would be different to loading it on the main window? Portals sound like just a technical UX solution, but would still cou

by keiru 7y ago

In what way loading a site on a portal would be different to loading it on the main window? Portals sound like just a technical UX solution, but would still count as site traffic.

JoshMnem 7y ago
It looks like a way to sort-of link to a site, but to make the default action to return back to the linking site instead of going deeper into the other site. You aren't sending people to the target page, but are just loading a preview. As the target website, even if your analytics show a visit, it might not be a full visit. 15 years ago, it was common for website owners to ask you to "make all links open in a frame" so that the original site could keep a frame on top of all the other content. That was probably only stopped by JavaScript snippets to break out of frames. Portals is the same kind of idea -- give power to the sites that link out (like Google) at the expense of the smaller sites that receive links.
altfredd 7y ago
> In what way loading a site on a portal would be different to loading it on the main window? The difference is made crystal-clear in the draft [1]: > Every browsing context has a portal state, which may be "none" (the default), "portal" or "orphaned"... "orphaned": top-level browsing contexts which have run activate but have not (yet) been adopted In other words, the original google.com document will be kept active in background (in "orphaned" state) and the child document can continue to interact with it by using Javascript after "adopting" it (at which point roles reverse and google.com becomes child document itself). In theory the specification allows child document to ignore parent and let browser close it, completing transition. It also allows to perform graceful switching between child and parent, keeping each in control as long as it remains top document. In practice, child portals will run Javascript, written by Google, and will be subject to Google's complete discretion. The distinction between first-party and third-party scripts will be erased, effectively letting Google run analytics on third-party domain, and send results back from it's own domain via Javascript proxy. [1]: https://wicg.github.io/portals/ https://wicg.github.io/portals/

by keiru 7y ago

In what way loading a site on a portal would be different to loading it on the main window? Portals sound like just a technical UX solution, but would still count as site traffic.

JoshMnem 7y ago

It looks like a way to sort-of link to a site, but to make the default action to return back to the linking site instead of going deeper into the other site. You aren't sending people to the target page, but are just loading a preview. As the target website, even if your analytics show a visit, it might not be a full visit. 15 years ago, it was common for website owners to ask you to "make all links open in a frame" so that the original site could keep a frame on top of all the other content. That was probably only stopped by JavaScript snippets to break out of frames. Portals is the same kind of idea -- give power to the sites that link out (like Google) at the expense of the smaller sites that receive links.

altfredd 7y ago

> In what way loading a site on a portal would be different to loading it on the main window? The difference is made crystal-clear in the draft [1]: > Every browsing context has a portal state, which may be "none" (the default), "portal" or "orphaned"... "orphaned": top-level browsing contexts which have run activate but have not (yet) been adopted In other words, the original google.com document will be kept active in background (in "orphaned" state) and the child document can continue to interact with it by using Javascript after "adopting" it (at which point roles reverse and google.com becomes child document itself). In theory the specification allows child document to ignore parent and let browser close it, completing transition. It also allows to perform graceful switching between child and parent, keeping each in control as long as it remains top document. In practice, child portals will run Javascript, written by Google, and will be subject to Google's complete discretion. The distinction between first-party and third-party scripts will be erased, effectively letting Google run analytics on third-party domain, and send results back from it's own domain via Javascript proxy. [1]: https://wicg.github.io/portals/ https://wicg.github.io/portals/