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.
Google launches new “portal” HTML element
181–190 of 265 posts
Re: Google launches new “portal” HTML element
#182Earlier quoted context omitted.
I don’t use an Adblocker due to ethical concerns. (Not trying to convince you to do the same, just explaining.) It’s, uh, really not that bad. I rarely notice banner ads and the like. If a particular site gets really egrigious, I leave the site. I suspect that after using Adblock for years, your brain has forgotten how to ignore them.
It’s, uh, really not that bad. I rarely notice banner ads and the like. If a particular site gets really egrigious, I leave the site. Yeah, I never understood why people purposefully visit sites full of ads and then complain that the sites they visit are full of ads. It seems like a pretty simple problem to solve. And yet, even among the tech crowd, people seem to struggle with it constantly.
What you notice is a really subjective argument. I notice ads, even "small" ones; they distract my attention, and annoy me.
I'd wish I had your ability to "rarely notice banner ads", but I don't, so I complain.
Re: Google launches new “portal” HTML element
#183“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 t…
My expectation is that you could only do this for the same domain.
If that is true, how would that interact with signed exchanges[0]?
[0] https://developers.google.com/web/updates/2018/11/signed-exc...
Re: Google launches new “portal” HTML element
#184> 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-…
Clunkier? To me, this new tag proposal screams AMP, which Google wants to remain fast.
Re: Google launches new “portal” HTML element
#185Earlier quoted context omitted.
> "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.
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.
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.
Re: Google launches new “portal” HTML element
#186It's not in the list here https://mozilla.github.io/standards-positions/ and the spec (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?
Re: Google launches new “portal” HTML element
#187Earlier quoted context omitted.
It took me a few months to realize that when I browse google with my iPhone and click a link, it's not actually taking me to that site, just loading it in an iframe. Weird and unnecessary, except in the eyes of Google's margins.
They also hijack the scrolling and often break parts of the site, I hate AMP with a passion.
The scrolling issues were due to a Safari bug. Unfortunately, Apple does not allow its users to install non-buggy browsers on their devices. I hate Apple devices with a passion.
Re: Google launches new “portal” HTML element
#188Earlier quoted context omitted.
I've had a similar experience as the GP, and I find it awful that autoplay videos will follow you around the page, pop-up modals will interrupt you in the middle of reading something, and ads will take up 40% or more of the page, loading between paragraphs while reading. It's hugely distracting to me. We could make the same argument: you've spend years without adblock, and they have worn you down to the point where y…
I've had a similar experience as the GP, and I find it awful that autoplay videos will follow you around the page, pop-up modals will interrupt you in the middle of reading something, and ads will take up 40% or more of the page, loading between paragraphs while reading. It's hugely distracting to me. Why would you ever spend time on a site that did these things? Even if you have an adblocker, why would you use such…
You don't always know what a link is going to serve you before you go there.
Re: Google launches new “portal” HTML element
#189> 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-…
The spec goes into detail of why existing tech (iframes) aren't enough: https://github.com/WICG/portals/blob/master/explainer.md#faq... https://github.com/WICG/portals/blob/master/explainer.md#alt...
To be clear, this FAQ isn't actually part of the spec (which I'm counting as the document here: https://wicg.github.io/portals/).
Re: Google launches new “portal” HTML element
#190At 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 el…
Embrace, extend, extinguish.