Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML portal element (Portals) #157

Closed
birtles opened this issue May 8, 2019 · 4 comments · Fixed by #345
Closed

HTML portal element (Portals) #157

birtles opened this issue May 8, 2019 · 4 comments · Fixed by #345
Labels
position: defer venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG)

Comments

@birtles
Copy link
Member

birtles commented May 8, 2019

Request for Mozilla Position on an Emerging Web Specification

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
Copy link
Contributor

dbaron commented May 8, 2019

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

@annevk annevk added the venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG) label Jun 25, 2019
@annevk annevk changed the title Portals HTML portal element (Portals) Jun 25, 2019
@kristoferjoseph
Copy link

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
Copy link
Contributor

dbaron commented Nov 16, 2019

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 added a commit to dbaron/standards-positions that referenced this issue May 23, 2020
@dbaron
Copy link
Contributor

dbaron commented May 29, 2020

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

annevk pushed a commit that referenced this issue May 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
position: defer venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants