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

111–120 of 265 posts

Re: Google launches new “portal” HTML element

#111

Post by Touche »

vernie wrote: post #105
Touche wrote: post #101

Earlier quoted context omitted.

I don't understand the cynicism people have for this idea. All they did was say "wouldn't it be cool if you could have nice animations in between pages" and built a proof-of-concept. It's not a finished product. They aren't forcing it into a standard. It's a demo of something that would be cool. So why the heck are people opposed to that?

Well you certainly can't raise a stink after it's in the standard.

My point is, portal isn't "an iframe without all the security protections." portal is a demo of animating between pages. What it becomes from there is completely flexible.

Re: Google launches new “portal” HTML element

#112

Post by username223 »

Ajedi32 wrote: post #96
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.

No, the purpose of the W3C is to make sure we don't end up with multiple slightly different, mutually incompatible variations of the same thing. It's not meant to be a gatekeeper for new features. That said, Portals _are_ going through the normal W3C process for experimental features via the Web Incubator Community Group: https://wicg.github.io/portals/

And the "standard" is written entirely by Google, and soon to be released in Chrome. The W3C and IETF are so thoroughly captured as to be little more than two small technical documentation groups at Google. It's the old Microsoft playbook, disguised at the expense of two decreasingly-credible industry standards bodies.

Re: Google launches new “portal” HTML element

#113

Post by news_to_me »

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.

No it isn't. It leads to fragmentation of the platform, and pretty soon you'll start seeing "Works best in Chrome!" tags on websites, because developers are too lazy to implement fallback solutions where (or whatever other proprietary extension) isn't supported.

Re: Google launches new “portal” HTML element

#114

Post by asadlionpk »

JoshMnem wrote: post #104
tangue wrote: post #10

We got rid of iframes, flash and WAP/imode. Thankfully we have now , Flutter and AMP.

Flutter looks like the junk food of programming. It looks like you get a choice between McDonald's (Google / Material Design) or Burger King (Apple). People are giving up long-term technology freedom for short-term, beginner's convenience.

People said the same about JavaScript. Probably C too.

Easier development = more developers.

Re: Google launches new “portal” HTML element

#116

Post by julienreszka »

amelius wrote: post #56

I once tried to put Google Search in an iframe, so I could put some handy buttons on top of it. It was not allowed. Perhaps "portals" are the solution (?)

I tried the same with top 50 most visited websites. https://julienreszka.github.io/dome/

Re: Google launches new “portal” HTML element

#117

Post by oo0shiny »

bryanlarsen wrote: post #32
y4mi wrote: 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.

Or the Brave browser, which has ad blocking built in.

Re: Google launches new “portal” HTML element

#118

Post by skymt »

skybrian wrote: post #107
skymt wrote: post #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.

If you're reading about this looking for how Google might misuse it, and that's what you see, then it seems like you're reading it as you intended. This isn't surprising. Many things can be read more than one way with only a little imagination. But there are other ways to read things. Like, how could I use that on my site? I'm thinking it might be fun to do something like the infinite zoom that Scott McCloud wrote ab…

It's true that I could be lacking imagination. Because to me the portal proposal reads like it's simply moving the implementation of Google's AMP carousel into the browser in order to solve the address-bar problem. Your suggested use cases aren't terribly convincing, I'm afraid. Zooming UIs are perfectly possible using existing web technology. It would be interesting to have a standard way to embed Twitter/Facebook-style preview cards, but portals aren't it. A portal would just display a small portion of the page, which wouldn't be terribly useful unless the page is designed to reformat itself when displayed inside a portal viewport. If you want link previews now, there's nothing stopping web application developers from fetching the Open Graph metadata themselves.

Re: Google launches new “portal” HTML element

#119

Post by codemac »

skymt wrote: post #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.

Serious question: what are the substantial security considerations?

I've been embedding websites in a tiddlywiki instance for todos as a test run, and I was surprised how much every website now tries to avoid/stop iframes due to the fact they aren't a "root" element.

This type of HTML element would allow me to build a web application that actually leverages other websites w/o click jacking. This is so powerful, it's what makes emacs and other ubiquitous interfaces so powerful. Leveraging other content

But maybe that's a pipe dream? Maybe that should be an application outside of the browser? Curious if there are any resources on the security implications of

Post reply on HN