
Google launches new “portal” HTML element - tannhaeuser
https://www.zdnet.com/article/google-launches-portals-a-new-web-page-navigation-system-for-chrome/
======
lqet
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 <base>-Tag inside the iframe.

> The advantage over using Portals over classic links is that the content
> inside portals can be pre-loaded while the user scrolls through a page, and
> be ready to expand into a new page without having the user wait for it to
> load.

What? What about the vast majority of links that appear in-line, in text
(think Wikipedia). What about the increased bandwidth usage for pre-loaded
pages I don't intend to visit? What about the obvious tracking issues? What
about the further increased difficulty for users to even tell which page they
are actually on, if the transition to another page is now smooth and not
clear-cut?

This article makes it seem like <portal> magically removes all the security
concerns people had for _decades_ with iframes, which imho is not the case at
all.

~~~
clairity
> "what about the obvious tracking issues?"

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.

~~~
ehsankia
How is prefetching taking the imperative away about what you see? You can
click or not click. As for "tracking", the website could already ping as many
servers as it wanted in the background, it's not like it can do anything new
here.

I honestly don't see how the server gets any more "power" than it already did.

~~~
tbirrell
If I go to foo.com, I generally expect that bar.com, baz.com, and qux.com are
not also loading.

We already have enough issues with tracking pixels, but now we'll have to
worry about multiple sites worth of trackers (which I'm sure google will do
their absolute best to obfuscate behind the background network call and other
sandboxing shenanigans)? No thanks.

~~~
ehsankia
As you mention, foo.com could just as well have pixel trackers/scripts from
bar.com, baz.com and qux.com. Nothing about portals makes it any more or less
of an issue than it already is.

~~~
throwaway2048
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)

~~~
ehsankia
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.

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

------
Grumbledour
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 the background can transition you seamlessly
to a new page. As quick as if you newer saw the content you intended to.
Progress! :-D

~~~
y4mi
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

~~~
giobox
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.

~~~
r3bl
I know it sounds complicated, but it's a one-step process that only increases
to pay off the more devices are connected.

I used to have four adblockers on my laptop (two operating systems x 2
browsers), one on my smartphone, one on an additional smartphone I use... and
how do I stop my TV and my ebook reader from serving me ads?

Pi-hole requires little to no maintenance, and offers a lot of benefit. Two
people have purchased their first Raspberry Pis after I've slipped in "oh and
BTW, no ads will load while you're connected to this network" after giving
them a WiFi password.

~~~
beanland
Are there any DNS servers on the public Internet that work similarly?

------
EastSmith
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.

~~~
ne01
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!

~~~
irrational
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.

~~~
netsharc
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!

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

Let's be real here. This can already be done though <link> "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...](https://stackoverflow.com/questions/49491193/how-can-i-preemptively-
load-a-web-page-or-resource/49491194#49491194)

~~~
smacktoward
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.

~~~
buzzert
More importantly, as it seems to require an implementation of native UI and
not just rendering, it will harm browsers that are currently Chromium based.

------
prepend
“Google says portals allow users to navigate inside the content they are
embedding --something that iframes do not allow for security reasons.”

I love how they gloss over the security issue here. This is the equivalent of
“we made a new Ajax that can call from different domains.”

Reading through the article, I don’t see the security restriction addressed at
all. I expect that this gets worked on when google submits this to the w3c to
be made part of html.

~~~
burtonator2011
My expectation is that you could only do this for the same domain.

~~~
ChrisSD
If that is true, how would that interact with signed exchanges[0]?

[0] [https://developers.google.com/web/updates/2018/11/signed-
exc...](https://developers.google.com/web/updates/2018/11/signed-exchanges)

------
jaredcwhite
At first glance, this seems really cool. Then I remember it's Google we're
talking about here. Somehow I feel like this is something they can use to
benefit their search engine and/or AMP-style efforts. Keep more users within
their controlled environments rather than officially navigating to a real
website elsewhere. Also seems like potential phishing problems could arise.
Can someone explain to me how this portal element to actually great and not
just great for Google?

~~~
parliament32
>Keep more users within their controlled environments rather than officially
navigating to a real website elsewhere

But that seems to be exactly what it does: look at the image at the top of the
article, the address bar clearly changes to the portal-target's location. I
think that's what they mean by "can be navigated into".

~~~
Spivak
Right but rather than making a seamless transition between pages they made it
a subpage of the parent.

Having built-in page previews is actually a useful feature but without the
other useful feature of

"play video" -> "click video to open page" -> "video continues playing while
the rest of the real page renders around it" -> "you are now really on the
other page with no connection to the previous page"

it seems like the business motivation for this was to embed more content in
Google Search while keeping Google branding in the background.

~~~
ddalex
This. It can allow you to see the google results and navigate from them
seamlessly without actually leaving the top-level domain. It effectively
captures the entire audience. There will be no more Internet, it's going to be
a Google portal (like AOL) with Google keywords, and will "borrow" the content
from everybody else.

~~~
co0nsta
How do you define "actually leaving"? Because after navigating to the portal,
it occupies the whole viewport and becomes the main document with your site's
URL.

Even if we assume you use AMP, package it with signed exchange, and Google
SERP displays it then, yeah, your site could appear with no extra network
request to your site. The lack of network requests isn't that different to old
school HTTP proxies but with better specs and security. AMP has analytics and
stuff so if you want to count visits, go do that.

I think the problem these technologies are meant to solve is making navigating
between pages take under a hundred milliseconds and appear much faster by
being able to preview/animate them. That would be good.

Yeah, new technology is not without cost and risks but Google turning the web
into a walled garden isn't high on my list of risks.

------
michaelt

      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?

~~~
neilalexander
I think it's largely a user experience thing. Because the "portal" has already
been loaded and rendered, you don't need to add the delay of loading the new
page at the point of navigation.

~~~
rst
But if performance boosts from preloading are all you want, you could just add
a 'preload' attribute to the usual <a> tag. The stated rationale of supporting
spiffy transitions seems a bit more sensible, though, given how many hooks
this has into browser UI, I'd be interested in seeing the limits on what, say,
a malicious ad network could do with it.

(Besides, if a page has several dozen links, exactly how many of them can you
afford to preload before that activity starts bogging things down? The ZDnet
article talks about this behavior replacing all links, which doesn't make a
whole lot of sense to me...)

------
atonse
Also just realized, as much as people like to push all the snark about
Microsoft regarding Embrace, Extend, Extinguish, that's exactly what Google is
doing right now.

With them dominating browser share, they can now push tags like this that only
make ads more annoying.

Geez we so badly need a more balanced browser landscape.

~~~
strictfp
The good thing is that they are already starting, so that the red flags are
risen early.

~~~
evv
Have you considered that it is already too late? Just look at Microsoft
bending the knee to Chromium

~~~
sixothree
I wonder if Chrome browser could survive if it was spun off from parent
company.

~~~
FridgeSeal
Google wouldn't allow that, as that would remove one of their primary means of
influencing things in their favour.

------
JoshMnem
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, Extinguish. The only conclusion I can come to about things like AMP
and portals is that Google is actively trying to kill the Web.

> "Google engineers hope that their new Portals technology will take over the
> web and become the standard way in which websites transition between links."

~~~
keiru
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.

~~~
altfredd
> 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/](https://wicg.github.io/portals/)

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

~~~
neilalexander
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?

~~~
molf
We are, by using and recommending browsers not owned by advertising
conglomerates.

~~~
neilalexander
I'm a very happy Safari user but evangelism is only going to get you so far.
There need to be better alternatives.

------
skymt
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.

~~~
mysterydip
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.

~~~
ahupp
> 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.

~~~
news_to_me
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 <portal> (or whatever other
proprietary extension) isn't supported.

~~~
moreira
I already see them all the time, but this time dressed up as “please upgrade
to a modern browser. But not Firefox. Not Safari. Definitely not Edge.”

~~~
ddalex
Perhaps Edge. A recent version.

------
tangue
We got rid of iframes, flash and WAP/imode. Thankfully we have now <portal>,
Flutter and AMP.

~~~
JoshMnem
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.

~~~
asadlionpk
People said the same about JavaScript. Probably C too.

Easier development = more developers.

~~~
JoshMnem
Flutter is restrictive in ways that JavaScript isn't.

------
verisimilitudes
>Google engineers hope that their new Portals technology will take over the
web and become the standard way in which websites transition between links.

This is marketed as being similar to the iframe tag, but it's really an attack
on the a tag.

~~~
config_yml
Yes, with the benefit that the site which opened the portal (or link) still
has control over the target.

Sounds fishy and they’re trying to project this under a UX umbrella.

~~~
max76
Sure, so now Google will have an easier time following your around after you
visit their search page. All results will open portals.

~~~
ddalex
you'll never leave the google top domain ever again

you wouldn't even know you're not leaving it, because the address bar changes

------
bArray
> Furthermore, portals can also overwrite the main URL

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

------
nine_k
I had to double-check that it's not an article form 1999 or something, when
everyone was building "portals", with a very similar premise of having
everything in one place [1].

It took mere ~25 years in the industry to see things making rounds and old
ideas coming back as new, unironically. X Terminal and "network computers" →
browser, JVM → WASM, CGI → serverless, Modula/Oberon → Go; now <iframe> →
<portal> and the whole idea around it.

[1]:
[https://en.wikipedia.org/wiki/Web_portal](https://en.wikipedia.org/wiki/Web_portal)

------
option_greek
>[https://github.com/WICG/portals/blob/master/explainer.md](https://github.com/WICG/portals/blob/master/explainer.md)

>This is a proposal for enabling seamless navigations between sites or pages.
In particular, this proposal enables a page to show another page as an inset
and perform a seamless transition between an inset state and a navigated
state.

Like clicking on an ad ?

------
fimdomeio
But is it "google launches" or "google proposes"? I think semantic details
matter a lot here. The article is written in a way that it makes it look like
W3C does not exist.

~~~
ergothus
Agreed. There's one line about a drafted standard, along with a note that no
other browser vendor has expressed interest.

I do not want to return to the days of incompatible browsers (to the degree it
was) even if they now publish a draft of how it works - the goal is
compatibility, not POTENTIAL compatibility.

------
dag11
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?

------
svieira
The reason for a new element, rather than just tacking this behavior onto
`iframe` seems to be backwards compatibility [1].

> We wish to give user agents as much flexibility as possible to isolate the
> host and guest browsing contexts (in implementations, in separate
> processes), even when the active documents may be same origin-domain. To
> make this possible, we intend not to expose the Document or WindowProxy of
> the guest contents, via the IDL attributes on HTMLIFrameElement, by using
> access to named windows, or by indexed access to window.frames. Without such
> access, communication can be be guaranteed to be asynchronous and not
> require shared access to JavaScript objects. Those operations which don't
> apply to portal contexts would all need to be modified to throw an
> appropriate exception in such cases.

[1]:
[https://github.com/WICG/portals/blob/master/explainer.md](https://github.com/WICG/portals/blob/master/explainer.md)

------
dkonieczek
I enabled portals in Canary and tested out the demo. For some reason after the
portal has activated, I can no longer go back to the previous page. So much
for "take over the web and become the standard way in which websites
transition between links". I wonder how much this will confuse the average
user. I hope that this is still due to it being experimental.

------
progfix
Do they use their internet dominance to invent a bunch of complex html
elements so google becomes the only one being able to parse html effectively
in the future? I hope not.

~~~
neilalexander
I don't think Google can be wholly blamed for that dominance. It's only
natural that they would want to invent their own web rendering engine and with
it they can pretty much choose what they do.

What's less natural is that so many other browsers/frameworks chose to be
based upon it (like every Electron app in the world, Opera, Silk, Microsoft
Edge real soon now™). Apart from Safari or Firefox, there aren't really many
alternatives anymore.

~~~
AnIdiotOnTheNet
It's the natural consequence of people clamoring to turn a simple hypertext
engine into a full on application VM. Feature upon feature was piled on,
producing a gigantic ludicrously complicated garbage fire the likes of which
simply cannot be replicated by mortals, and to ensure this whoever is on top
will keep adding to the garbage fire so no one can ever catch up.

Web devs and evangelists of the world, you brought this on yourselves.

------
rlv-dan
1999: Microsoft launches new HTML tag 2019: Google launches new HTML tag

------
lol768
It's not in the list here [https://mozilla.github.io/standards-
positions/](https://mozilla.github.io/standards-positions/) and the spec
([https://wicg.github.io/portals/#the-portal-
element](https://wicg.github.io/portals/#the-portal-element)) is written
solely by folks at Google and doesn't appear to be an actual W3C spec. Why
should anybody care about this until it's standardised and implemented by more
than one browser vendor?

To talk of a browser vendor "launching" a new element is also ridiculous -
Google have no authority to "launch" an element for the web as if it were some
product they decided to update. Article title is poor in this respect.

Looking at the actual spec:

> This specification extends [HTML] to define a new kind of top-level browsing
> context, which can be embedded in another document, and a mechanism for
> replacing the contents of another top-level browsing context with the
> previously embedded context.

1) Why not an iframe? 2) Why not a link to the iframe src?

Or is the link here from within the iframe? Surely that's possible already
with a postMessage and a window.location change. I don't understand the
benefits here.

Is the sole purpose of this to avoid a HTTP request?

~~~
p4bl0
I agree with most of your comment. However, I don't think the claim that
Google is launching a new element is ridiculous (even if I'm sad about it).
That's more or less how it worked during the IE vs Netscape war. Remember
those fancy <marquee> and <blink> tags for example. Standardization came
second.

------
zbrozek
I don't understand why I should have any desire for this.

~~~
dane-pgp
Depending on how it interacts with SRI, there is one interesting use case that
could be supported. Imagine you had a data-uri / bookmarklet which loaded a
<portal> of a web app, using the ideas discussed here:

[https://news.ycombinator.com/item?id=17776456](https://news.ycombinator.com/item?id=17776456)

If the SRI hash on the data-uri could restrict the content of the portal to a
trusted HTML document (containing SRI hashes for the scripts it referenced),
then navigating "into" the portal would allow the browser to display the URL
of the origin site, and run JavaScript in that context, with the TLS indicator
visible.

This would allow us to pin specific versions of web apps (if they were
structured this way), and those apps could be subject to independent audit.
Specifically, it would then be impossible for a compromised host to silently
"upgrade" you to a new malicious version of the web app (or even downgrade you
to an earlier version).

------
skybrian
The idea seems to be able to show a preview of a page, then navigate into it
if the user chooses, without reloading it. Here is an explainer:

[https://github.com/WICG/portals/blob/master/explainer.md](https://github.com/WICG/portals/blob/master/explainer.md)

------
ivarv
Throwback to 2003! At first glance this seems _very_ reminiscent of the Java
Portlet standard -
[https://en.wikipedia.org/wiki/Java_Portlet_Specification](https://en.wikipedia.org/wiki/Java_Portlet_Specification)

------
makecheck
A substantial amount of browsing is now done on battery and expensive data
plans so “no thanks” to all these preload-100-things technologies. Just waste,
multiplied by more waste.

------
leshokunin
Great. This looks like another feature for AMP, but disguis.. I mean packaged
as something generic. I’m really not fond of how Google is driving AMP as the
go-to way to get better visibility on Google. This is going to introduce more
headaches and very little to no upside. I don’t understand why they keep
building things without talking to the user. There are other users than Google
developers out there, and very little demand for AMP.

------
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 <a> 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).

------
amelius
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 (?)

~~~
julienreszka
I tried the same with top 50 most visited websites.
[https://julienreszka.github.io/dome/](https://julienreszka.github.io/dome/)

------
founderling
I would be surprised if Google would allow to "link" to their page by putting
it in a portal tag.

Just like they don't allow putting their pages in iframes:

[https://jsfiddle.net/yea0jvxL/](https://jsfiddle.net/yea0jvxL/)

But I would not be surprised if they put all search results in portal links
and therefore keep all users on their site.

------
throwaway55554
Wait! Seriously? Did IE of yore _not teach anyone anything_??? Or does the
internet truly have that short of a memory span?

~~~
AnIdiotOnTheNet
Yes

------
bluepnume
I wrote a quick article on the differences between portals and iframes:
[https://medium.com/@bluepnume/google-chromes-portals-like-
if...](https://medium.com/@bluepnume/google-chromes-portals-like-iframes-but-
better-and-worse-29e0bbb3f78e)

------
yason
I think things started to go more or less downhill since HTML 2.0. For the
kind of web browsing I'm used to value text and images go a long way and they
don't really allow for anything too intrusive. There were tons of interesting
sites online in the 90's and basically none of them were bad because they were
missing some essential interactive page/UI elements. Most of them were near-
instant already at the time if you had something better than a modem
connection. Things could've gone heavenly if the nerds who built that only
weren't a minority. At least we still have text terminals and ssh...

------
amenod
I really, really, _really_ hope this is never supported by other browsers.

------
busymom0
I honestly don't see the point of this unless it gets widely adopted by other
browsers (which is an obvious point). Mobile is already a huge market and on
iOS at least, even chrome and safari simply use the iOS built in WKWebView
with a UI wrapper around it. So unless Apple decides to include <portal>,
wouldn't this not work on any iOS browsers? I also use Android but don't use
Chrome due to it's lack of extension and content blocker support. So other
browsers on Android will also need to adopt this.

------
rangerpolitic
I am growing increasingly annoyed with "user experience." It's becoming a
catchall excuse for Google and others to inject all kinds of crap that no one
wants.

------
jpalomaki
Reminds me of the old Google Caja project. ”The Caja Compiler is a tool for
making third party HTML, CSS and JavaScript safe to embed in your website. It
enables rich interaction between the embedding page and the embedded
applications.”

[https://developers.google.com/caja/#benefits-of-using-
caja](https://developers.google.com/caja/#benefits-of-using-caja)

------
partiallypro
I don't know why anyone would truly adopt this. It's very Google centric and
didn't have any major benefits outside YouTube ad sales.

------
atonse
I hope ad blockers can universally block this tag. This seems like an attempt
for them to make ads even more annoying.

~~~
zzo38computer
Or just replace them with normal links (or iframes, depending on the user
setting).

------
kerng
Google indeed is the new Internet Explorer with adding these random, of course
standardized and open features.

------
hn23
Google is really becoming the MS of these days... "This page is optimized for
Chrome."

------
jug
Am I back in the late 1990's?

~~~
layoutIfNeeded
<marquee>yes</marquee>

------
cromwellian
The headline is wrong, nothing was 'launched', rather, an experimental feature
was added to chrome://flags, just like the gazillions of other features that
are hidden behind flags until they are standardized and shipped.

------
ilaksh
Is Firefox going to implement it? Seems like a lot of pressure on that team to
ensure it makes sense. And if they find a reason not to implement it they may
be really screwed because of the control Google has.

------
antibland
The best-case scenario for the future health of the web is for Mozilla to
resist supporting <portal>, which will hopefully dissuade companies from
adding this element to their products.

------
yellowapple
Embrace -> [Extend] -> Extinguish

Now that Chrome is quickly becoming (if not has outright become) the new
Internet Explorer, I wonder what browser will come out in a few years to be
the next Chrome?

------
thefounder
This seems designed to stop people leaving Google search/news

------
Liron
So many snarky comments here. Chill. Portal is just an iFrame that has the
ability to smoothly transition itself into being the top-level URL while
maintaining its inner state.

------
_bxg1
Welcome to a world in which "web standards" are just everyone else trying to
keep in step with whatever Google launched this week.

------
ThinkingGuy
I read this:

 _" The advantage...is that the content inside portals can be pre-loaded while
the user scrolls through a page, and be ready to expand into a new page
without having the user wait for it to load."_

My brain translated it to this:

 _" The advantage...is that advertisements can be pre-loaded while the user
scrolls through a page, and be ready to add to Google's revenue without having
the user to wait for it to load."_

~~~
zihotki
So shall we expect that google will penalize in search results the sites which
don't use new "portal" element as they do now with AMP?

------
jonathankoren
This isn’t a W3C element, correct? So it’s Microsoft’s embrace and extend
strategy.

------
ConcernedCoder
Oh! I'm sure that won't be exploited by hackers... thanks google.

------
Jtsummers
> Google launched a new technology called Portals

How is an HTML tag a technology?

------
jeena
Interesting that nowadays Google is launching HTML elements.

------
vernie
AMP is fast, yes. Everything else about it fucking sucks.

------
pier25
Is this coming to Chromium/Blink or only Chrome?

~~~
shakna
It's been under the experimental flags in Chromium since August.

------
pragmaticalien8
what junk did this zdnet.com load from tru.am?

------
julienreszka
This is so cool.

------
sexyflanders
Annnd thats why I don't run chrome

