Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google launches new “portal” HTML element

zdnet.com

Post reply on HN
Print view View original

241–250 of 265 posts

Re: Google launches new “portal” HTML element

#241

Post by netsharc »

irrational wrote: post #234
ne01 wrote: post #212

Earlier quoted context omitted.

I'm so happy that duckduckgo.com is getting better and better over time. I tried to use it for a month 2 years ago and switched back to Google. Now it has been 3 months and I don't notice -- which is a very good thing!

I've been using duckduckgo as my sole search engine for years. I've been totally satisfied with my results. In fact I've had other people mention how my googlefu is exceptional since I'm always finding stuff that they can't seem to find. It just occurred to me that maybe it's the search engine that I'm using instead of my search skills.

Either my google-fu is failing me, or Google changed so much that my fu isn't working anymore. I feel Google is so fucking terrible now, I was looking for an obscure DOS game, and the word "game" lead it to show me games on the app store...

Or, it would show pages with just 2 out the 3 search terms I give it. And guess which word they'll leave out? The word that makes the search specific instead of broad... god effing damnit!

Re: Google launches new “portal” HTML element

#242

Post by throwaway2048 »

cromwellian wrote: post #221
rangerpolitic wrote: post #89

Earlier quoted context omitted.

> They're not doing this as they see fit. Sure they are. It's already part of Chromium. https://cs.chromium.org/chromium/src/content/browser/portal/... It's been there since at least last August.

It's turned off by default.

not for long

Re: Google launches new “portal” HTML element

#243

Post by altfredd »

keiru wrote: post #93
JoshMnem wrote: post #86

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, Ex…

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.

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

Re: Google launches new “portal” HTML element

#244

Post by altfredd »

ahupp wrote: post #88
mysterydip wrote: post #81

Earlier quoted context omitted.

Isn't this why we have the W3C, so standards don't get made unless multiple people benefit? This seems like Microsoft with IE6 all over again.

> This seems like Microsoft with IE6 all over again. IE6 gave us XMLHttpRequest because they wanted it to build Outlook for the web. That seems like it turned out ok. In general I think building browser-specific features, seeing what works, and only then standardizing is a much better path than starting with W3C.

> IE6 gave us XMLHttpRequest because they wanted it to build Outlook for the web. That seems like it turned out ok.

That depends on one's definition of "ok". I don't think that modern web is ok.

Re: Google launches new “portal” HTML element

#245

Post by chronicler »

ehsankia wrote: post #238
throwaway2048 wrote: post #237

Earlier quoted context omitted.

Its completely different because now baz.com gets control over foo.com in an invisible way just by virtue of "linking" with a portal. (and you can be sure that anyone that dosen't allow google to "portal" their pages will be damnatio memoriae'd into oblivion on results pages)

baz.com doesn't take control over foo.com, and it's not invisible. You click on a link and the domain changes, it's as old as the internet itself. The only difference is that the new page will be embedded into the old one, instead of there being a clear cut transition.

Everyone seems to have just jumped into the 'Google is evil' bandwagon without even putting thought into it.

Re: Google launches new “portal” HTML element

#246

Post by kinlan »

EastSmith wrote: post #195

Looks to me as an effort to make any user visiting google.com to not actually leave google.com FOREVER. Users will get portal-ed to a result page (with the browser's url bar showing foo.com, instead of google.com), but the user will be tracked the entire time from google, since they would be still on google.com.

With a portal, you are not on the original origin at all, you are on the new site once it's activated - I think you're thinking of signed exchanges which enable CDNed like experiences.

Portals are essentially iframes, but once activated they become the top level origin.

Re: Google launches new “portal” HTML element

#247

Post by hughw »

Wowfunhappy wrote: post #140
kermitismyhero wrote: post #51

Earlier quoted context omitted.

The recent extension-disabling problem made me realize how awful the unfiltered web is. Trying to use mobile Chrome for the first time ever was a dreadful experience. I legitimately had no idea that mobile Chrome doesn't have any extension capability whatsoever. I always assumed it was a Firefox-style unified experience where the same desktop extensions worked on mobile. I was horrified to discover otherwise. Ads ads…

I don’t use an Adblocker due to ethical concerns. (Not trying to convince you to do the same, just explaining.) It’s, uh, really not that bad. I rarely notice banner ads and the like. If a particular site gets really egrigious, I leave the site. I suspect that after using Adblock for years, your brain has forgotten how to ignore them.

To be truly ethical, you must watch the ads.

Re: Google launches new “portal” HTML element

#248

Post by MentallyRetired »

paulirwin wrote: post #19
tinus_hn wrote: post #7

I don’t like how Google now gets to ‘launch new HTML elements’ as they see fit for their own purposes.

> as they see fit They're doing this in the open through the W3C WICG process [1]. They're not doing this as they see fit. > for their own purposes. Open standards are available for anyone to use and benefit from. That they may have had a use case in mind when defining the spec does not invalidate it; rather, it reinforces it and shows its value. 1: https://wicg.github.io/portals/

>They're doing this in the open through the W3C WICG process [1]. They're not doing this as they see fit.

They launched the draft on the 2nd and implemented the tag on the 10th. I'd hardly call that going through the open process. That's a move to save face.

Re: Google launches new “portal” HTML element

#249

Post by cromwellian »

throwaway2048 wrote: post #242
cromwellian wrote: post #221

Earlier quoted context omitted.

It's turned off by default.

not for long

Sure, if it gets approved as a standard. Why not go look at the history of other HTML, CSS, and JS API additions, and the way they were staged, and what percentage shipped without agreement from other stakeholders?

Start at https://www.chromestatus.com/features/schedule you can drill down from there, for each feature, you can see links to W3C, WICG, TC'39, or whatever repositories, complete with discussion, and status from other browser vendors.

Yes, Chrome has shipped proprietary API features "on by default" before without buy-in from everyone else (e.g. NaCL), but so has Mozilla. The question is, are these the exception, or the rule?

And in my view, most of the Web's evolution in the past few years has been way more open and participatory than the 90s/00s Netscape/IE era.

Re: Google launches new “portal” HTML element

#250

Post by altfredd »

kinlan wrote: post #246
EastSmith wrote: post #195

Looks to me as an effort to make any user visiting google.com to not actually leave google.com FOREVER. Users will get portal-ed to a result page (with the browser's url bar showing foo.com, instead of google.com), but the user will be tracked the entire time from google, since they would be still on google.com.

With a portal, you are not on the original origin at all, you are on the new site once it's activated - I think you're thinking of signed exchanges which enable CDNed like experiences. Portals are essentially iframes, but once activated they become the top level origin.

If portals really were iframes, there would be no reason to create them.

Google is completely open about their intentions. Citation from https://github.com/WICG/portals/blob/master/key-scenarios.md:

> After being activated, a portal opened by the news aggregator will now receive the input events. This means that it will have to co-operate with the news aggregator in order to maintain the desired user experience.

Why exactly does it _have_ to cooperate? And _how_ can it cooperate? Will it be enough to include a script from parent domain? Will analytics be part of "desired user experience"? Will parent domain ban a site from it's index for trying to "break out"?

It is essentially impossible to build relationships of mutual trust to the point when one website can freely embed another... unless one party has overwhelming power advantage. Who is the target auditory of ? What "news aggregator" has enough leverage to make pages switch back to it as told to? If such "aggregator" existed, I would not trust it to make web browsers or dictate, how they should work.

Post reply on HN