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