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.
That depends on one's definition of "ok". I don't think that modern web is ok.
That said, Portals _are_ going through the normal W3C process for experimental features via the Web Incubator Community Group: https://wicg.github.io/portals/
W3C is a joke. The modern web is, like the old web, run by the dominant browser vendor. Calling it an open standard is just marketing.
If you want to contribute, there's a repo full of issues that's completely public: https://github.com/WICG/portals/issues
So why the heck are people opposed to that?
https://people.apache.org/~jim/NewArchitect/webrevu/1998/12_...
in that scenario “wouldn’t it be cool” is not a good enough reason, and for a major feature such as this, skepticism is healthy and warranted... the “web browser” is slowly being transformed into “the google browser” and we have no one to blame but ourselves
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 < portal >
JS-based “iframe busters”, then X-Frame-Options, and now Content-Security-Policy should be ubiquitous. We started “busting iframes” in they early 2000s in the banking industry for security reasons.
Preventing being an iframe child protects your site from phishing via click-jacking your login screen, and also prevents “stealing” of your content by spammy aggregation sites.
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 about. Or more practically, it would let everyone put site previews next to links, like Twitter and Facebook do, without needing a big infrastructure.
Or you could think about how arbitrary hackers could misuse it. The security issues seem a bit concerning. But I suppose it could be blocked like iframes?
It doesn't seem all that unreasonable for a web page to show a preview if the window size is small enough. You could do that with a media query. And then when it goes full-screen, it would already be loaded and that would just be a resize.
This would take cooperation from web sites.
Building richer cross-site interactions into web standards and browser interfaces is an intriguing idea. A more dynamic model of hypertext, where the browser intelligently displays linked-to content. Even though portals are a highly limited version of that idea, Google has a high chance of getting them standardized and implemented by competing engines, so hopefully more useful applications can be found.
Embedded youtube videos could support a navigation to the video page where the video just animated from the embed to its in-page position while continuing to play.
Embedded twitter posts could be clicked on to do the same sort of transition. Really this sort of thing applies to all kinds of media embeds.
Amazon ads could do the same sort of transition to the advertised item.
Basically, this could allow multiple different domains to coordinate to get some of the fluidity that you can build on a single page. Ex. you could develop a federated social network of many different providers (or video sharing or whatever) while retaining the UX of interacting with a single thing.