Live data from Hacker News

Google launches new “portal” HTML element

zdnet.com

51–60 of 265 posts

Re: Google launches new “portal” HTML element

#51
post #30

Earlier quoted context omitted.

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

Or just switch to Firefox on Android and use uBlock Origin or similar.

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 ads everywhere. How do people actually live day-to-day with mobile browsers that have no true adblocking capability? Using mobile Chrome is like taking a stroll through a plague ward.

Re: Google launches new “portal” HTML element

#52

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…

> Does Silicon Valley not have data caps? I guess they never have bad reception, though.

Pretty much. When the developers only use the latest phones, on a company (or unlimited) plan, connected to 4G LTE with full bars, this is what you get. Google seems determined to hide network latency with its various prefetching efforts, but since I'm paying for bandwidth, I'd rather just wait the extra couple of seconds.

Re: Google launches new “portal” HTML element

#53
post #7

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

At the end of the day, web standards are nothing more than advisory and Google own a clear majority of browser market share. Who is going to stop them?

People used to say that about IE6, before Firefox and Chrome came along.

Re: Google launches new “portal” HTML element

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

So-called "Web Standards" processes and organizations have been a fairy tale for a long time now. W3C is a pay-as-you-go puppet organization dominated by Google. You can see who calls the shots just by considering that the W3C-HTML 5.3 and SVG 2 specs have been abandoned. WHATWG was also funded and is sponsored by Google, and made an aggressive attempt at usurpating de-facto power over web standardization with a vulgar, staged anti-establishment "HTML5 rocks" campaign. The dominating browser and mobile platform (again, Google) can do what they want anyway. Now they turn to W3C again as a fig leaf for their not-so-stealth operation to become the web.

WHATWG's and W3C's track record as wannabe standardization bodies is incredibly poor considering that it has seen Opera and MS drop out of browser development alltogether, and that web standards are so fsckng complicated it's infeasible to develop a browser from scratch again, ever. I mean, that's exactly the situation that a standard is meant to prevent.

It's time for a real standardization org to step in, and for society to sit at the table when it comes to decide on the primary means for digital communication.

Re: Google launches new “portal” HTML element

#57
> portals can be pre-loaded while the user scrolls through a page

Let's be real here. This can already be done though "prefetch" and "preload" [0].

This is just Google introducing more pointless tech that will make webpages clunkier for no good reason. Honestly, I can't think of a single purpose this serves that isn't already fulfilled by existing web tech.

[0]: https://stackoverflow.com/questions/49491193/how-can-i-preem...

Re: Google launches new “portal” HTML element

#58
What I don't understand is that many websites frame-bust to prevent phishing and click-jacking attacks on their content. But if Google wants to be accessible through portals, they'll have to open themselves up to the same phishing and click-jacking vulnerabilities, right?

Re: Google launches new “portal” HTML element

#60
Am I reading this wrong, or is Google pushing a fairly complex element with substantial security considerations into HTML exclusively to solve their UX problems with AMP and the pre-load search carousel? Like this seems like it would be a fair amount of work for browsers to implement, and Google is the only party who would benefit.
Post reply on HN