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

41–50 of 265 posts

Re: Google launches new “portal” HTML element

#41

Post by bbatha »

michaelt wrote: post #14

For example, engineers hope that when a user is navigating a news site, when they reach the bottom of a story, related links for other stories are embedded as portals, which the user can click and seamlessly transition to a new page. Perhaps it's not a very good description, but isn't that just a link? That sounds a lot like a link to me? So this example really doesn't make it clear to me why we need this new element…

> but isn't that just a link?

Its a modernized ifame. It seems like they can't introduce some of these features without breaking the security features of iframes.

Re: Google launches new “portal” HTML element

#43

Post by Insanity »

The example they give seems bad to me. I'm fine just seeing the title of a news post and clicking that as a normal tag. I don't need to see a miniature version of the post that I then need to click on to read anyway.

Also, the preview problem... you could really just use an image as a link if you wanted to. Less convenient, that's true. But meh, this tag seems to offer little extra (to me).

Re: Google launches new “portal” HTML element

#47

Post by true_religion »

lqet wrote: post #15

Can someone explain to me the innovation here, besides some page-transition eye-candy? > Furthermore, portals can also overwrite the main URL address bar, meaning they are useful as a navigation system Isn't this already possible with iframes and target="_top" / target="_parent"? You can also use the -Tag inside the iframe. > The advantage over using Portals over classic links is that the content inside portals can b…

With regards to bandwidth from pages you do not want to visit, sites can already include content that you do not care about in the page manually as part of the initial HTML or later via AJAX. In fact, the use case for portals covers this in that news sites commonly add other IMO irrelevant articles at the end of articles that I am reading.

Re: Google launches new “portal” HTML element

#48

Post by giobox »

y4mi wrote: post #30
Grumbledour wrote: post #24

It's kind of funny, how mobile today is a big part of traffic and this will only increase, yet while the mobile experience is already terrible, especially in chrome with no script blocker, google constantly works at making it even worse, with preloading of undesired, external content. Does Silicon Valley not have data caps? I guess they never have bad reception, though. So at least the malicious add that preloaded in…

If you're connected to a VPN, install pi-hole on that network and use it as dns. If not, just get blokada from f-droid. It uses 1-3% energy over the day on my phone, but saves around 15% by filtering ads

It’s a real shame you still can’t install a third party content blocker easily in the default browser on Android. Setup a VPN and PiHole for sure works, but my goodness what a lot of effort when simpler approaches exist, even on Safari on iOS... I’m aware other browsers exist that can do this, but this basically forces me to use a different browser on my phone versus my desktop.

Such is the reality of using an OS made by an advertising firm I guess.

Re: Google launches new “portal” HTML element

#50

Post by jmull »

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.

I really don't see a significant difference. They can pretty much propose whatever they see fit through WICG and implement it in Chrome as they see fit.

By the way, this isn't a standard by any reasonable definition of the word.

Post reply on HN