HTML portal element (Portals)

[birtles]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Portals
• Specification or proposal URL: https://wicg.github.io/portals/
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @annevk @bzbarsky @hsivonen

Other information

This is being promoted recently: https://web.dev/hands-on-portals

I believe bz had concerns regarding fallback when this was brought up in the blink-dev intent to implement.

[dbaron]

The feedback in w3ctag/design-reviews#331 was reasonably negative, although part of that was saying "this isn't even concrete enough yet for us to evaluate".

[kristoferjoseph]

IMHO this feature is one of the most exciting to come along in a while.
This addition alone could significantly cut down on the amount of JavaScript needed to make a web page feel like a web app.
I don't see a need for a fallback solution, because without it you would just experience the web as it is today, which arguably works pretty damn good.

[dbaron]

So my inclination is to mark it harmful with the following explanation:

The Portals proposal introduces a significant amount of complexity to the web without either (a) clearly explaining how it differs and doesn't differ from the iframe element or (b) a serious attempt to specify how it interacts with the large number of existing web features (including aspects of the origin model) many of which are critical for security and how it interacts with existing privacy features in web browsers. We believe the proposal as it exists today is harmful, but would be willing to reconsider given a more clearly motivated and clearly specified proposal.

This is probably a somewhat softer "harmful" than the two other proposals currently listed as "harmful".

What do you think?

[dbaron]

Since I'm trying to keep the substantive discussion in the issues rather than fragmenting it between issues and PRs, I'm going to copy of @domenic's comment at #345 (comment) here:

Hey folks!

I wanted to chime in here to express a bit of surprise at this position. Although I appreciate the open-ended sentence at the end, I'm not sure what to make of the rest. The portals proposal has extensive discussion of the differences between portals and iframes. And, at least the current draft fully specifies the interaction with all web platform features except session history. (Well, it actually fully specifies the interaction with session history, by using the top-level browsing context concept. But this creates too much implementer work for figuring out how to map session history to UI elements such as the back button, so we've had a long-standing acknowledged issue to detail that mapping in a way that makes it easier for implementers to give their users a good user experience.) Certainly, there is no confusion with the origin model in the current draft; it's not modified at all. Finally, although judgments of what are "significant" are subjective, I was under the impression from our meeting with @annevk in Berlin that we'd managed to keep the complexity pretty low, at least in his estimation. The spec is, after all, pretty short.

All that said! The real reason that I'd push for a "defer" instead of "harmful" is that the portals proposal is undergoing significant changes, in responses to the shifting tides over the last year or so in terms of storage partitioning efforts in browsers. As such, the current draft does not reflect what we intend to implement in Chromium. That's more captured in the explainer. And the explainer itself has a lot of gaps: if you squint at the various "TODO" sections I've added, you can get a sense of where we are heading, but it's not something I'd really encourage anyone to spend time on; we know there's work to do in laying out the proposed modifications to the storage restrictions and partitioning model, permissions, and rendering in a digestible format, first as an explainer, and then as a spec. (These will, unavoidably, increase the complexity of the spec a bit, perhaps even to "significant" levels, but we think this will be worth it for the privacy benefits.)

So, if it's possible under your process, we'd love to withdraw the current portals proposal from consideration. It's too much under-construction at the moment to be fairly judged. We're hopeful that the direction we're heading will make it more interesting to Mozilla. (That direction is, roughly, laser-focused on privacy-preserving prerendering, including accommodations for modern storage partitioning efforts.) It's certainly up to you whether you'd want to mark portals as "harmful" in the meantime, but I think it would be a bit strange, as the position is being taken on an older draft of the spec/explainer, and as mentioned above, seems to have some inaccuracies in how it read that spec/explainer.

(I'm going to revise the proposed position a bit in light of this.)

[trusktr]

IMHO this feature is one of the most exciting to come along in a while.

This feature would be super futurizing for the metaverse. Imagine websites (2D or 3D), and you can transition to other websites (2D or 3D). As a standard, this would make it possible to traverse worlds in 3D space in a shared way, relying on decentralized domain names for representing worlds.

Now imagine, for example, with optional communication between the websites (i.e. 3D worlds), the camera position of one world can be aligned with that of the nested world (i.e. real "portals" or doorways to other worlds).

I'm working on https://lume.io, which provides 3D custom HTML elements, and these are the sorts of things I envision being openly standardized in the future.

This is all possible right now, but it would be non-standard. For example, I could perhaps wire up some iframes and invent a way to communicate across the domains, share camera data, and make the "jump" across worlds happen.

However it would be very hacky to avoid a very bad UX. For one, there would necessarily need to be an infinite stack of iframes, otherwise any time one wished to traverse into a world there would need to be a full page reload to cause the nested iframe to become the top iframe so that it can take over the URL in the address bar, and that would be a really bad user experience. To avoid these full page reloads, we'd need to create a convention across coordinated websites so that they can support a URL format that can store the nested set of iframe domains in order to afford sub-navigation in each iframe, and this would get extremely complicated.

Native portals solve all the issues. As soon as we enter a portal, it becomes the top-level page, and controls the address bar, just as if we visited that website in the first place.

Portals would help us progress towards a true metaverse in a much more modern and standard way by natively handling worlds in worlds in worlds in worlds. URL address bar hacks would not be necessary, for example, as the browser would instead integrate natively into the browser history, there'd be no need to track a stack of iframes using APIs that are limited compared to the browser's own native APIs, etc.

---

Imagine this

• Imagine you're walking around a 3D world that looks like minecraft (for sake of example)
• you walk into a house
• in that house is a computer, or simply a floating panel, with a website in it, for example an online store.
• you could interact with the website, or you could enter it.
• you enter the website, which happens to be 2D, so now this 2D website takes up your window.
• you are exploring products on the 2D website.
• in the 2D website, you discover a portal to a 3D minigame that sells the product, so you click enter it.
• the view zooms in and you are now inside the 3D game for the product.
• you hit the back button, and you're back in the 2D store
• you bookmark the product for later, as currently you already spent all your money on stuff
• you hit the back button again and you get back into the minecraft-like world inside the home where you previously were
• You might be doing all this on a regular monitor, or you might be doing all this in a VR headset (f.e. Quest Browser or VisionOS Safari).

THIS. Is the future.