5 ms·

It's going to hurt small sites the most, because sources of traffic like Google, Facebook, and other large sites will eventually stop linking to websites, and l

It's going to hurt small sites the most, because sources of traffic like Google, Facebook, and other large sites will eventually stop linking to websites, and load them as previews in frames ("portals") instead. "No other browser vendor has expressed interest in supporting the Portals" -- but Google is releasing it in Chrome anyway. It changes the fundamental nature of the WWW as linked documents. Embrace, Extend, Extinguish. The only conclusion I can come to about things like AMP and portals is that Google is actively trying to kill the Web. > "Google engineers hope that their new Portals technology will take over the web and become the standard way in which websites transition between links."

superkuh 7y ago
> sources of traffic like Google, Facebook, and other large sites will eventually stop linking to websites, and load them as previews in frames ("portals") instead. That's already happening to an extent with local AMP caches of outbound links 3rd party links on AMP enabled pages at cloudflare.
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/

superkuh 7y ago

> sources of traffic like Google, Facebook, and other large sites will eventually stop linking to websites, and load them as previews in frames ("portals") instead. That's already happening to an extent with local AMP caches of outbound links 3rd party links on AMP enabled pages at cloudflare.

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/