71–80 of 265 posts
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.
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?
Dart ran natively in Chrome once. Why doesn't it now? Because webdevs didn't care enough to write native Dart on the front-end.
> 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-…
Portals are user-visible, so the browser can't defer the load.
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.
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…
frankly, tracking seems to be a primary purpose of the portal tag. it takes the imperative away from the user so that the server can make the decision about what you see and how intrusive it can be. the point seems to be to shift control to google.
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.
Google makes money off companies whose goal is to keep you in a mindless state of flow. Having to wait for a page to load disturbs that flow, making it more likely for you to realize you're being monetized and/or just wasting your time, and should do something else instead.
> 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-…
Link prefetch/preload puts the loading under the control of the browser. The user can't see whether it loads or not, so the browser can make intelligent decisions about when to load it or whether to even load it at all. Portals are user-visible, so the browser can't defer the load.
This is a good thing. Many are on metered connections and have data caps.
> 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-…
It's not pointless at all. It makes the Web platform more complicated to implement, which, as the company that owns the leading browser, is in Google's interest. The more complicated the platform becomes, the harder and more expensive it will be for any potential competitors to ship a product that can challenge Chrome.
> address bar, meaning they are useful as a navigation
> system, and more than embedding content --the most common
> way in which iframes are used today.
Well, this looks like the next hack/scam feature. I really hate to think of the sort of rubbish that this will cause.
> Google says portals allow users to navigate inside the
> content they are embedding --something that iframes do not
> allow for security reasons.
Surely this is exactly why the "portal" shouldn't do this either? Why not work towards fixing the security issues of the iframe?
Regarding pre-loading content in links, they could just implement this in the browser if they think it's really that important. This will destroy your mobile data.
I really wish they had sat down and discussed this with other browser teams to flesh it out. I think part of this is in getting the jump on other browsers, this really will take a long time to implement securely.