Skip to content

Conversation

@marcoscaceres
Copy link

@marcoscaceres marcoscaceres commented Nov 27, 2025

Reduce proposal down to absolute minimum.

This is motivated by the discussion we had at TPAC (minutes there):
w3c/manifest#1178

Reduce proposal down to absolute minimum.
@LiaHiscock
Copy link
Collaborator

Hi Marcos!

I understand that the TPAC discussion was centered around current document/parameter-less install, however the feedback we've received from partners remains overwhelmingly clear that cross origin installation is the valuable part of our install efforts. We expect same origin install to naturally fall out of our cross-origin efforts.

I'm happy to approve your simplifications in the problem/proposal, but our plan is to keep the cross-origin capabilities in this proposal.

@marcoscaceres
Copy link
Author

marcoscaceres commented Dec 2, 2025

Right, but I'll remind you of the TAG suggestions to scale this kind of proposal back:
w3ctag/design-reviews#1051 (comment)

And:
w3ctag/design-reviews#946 (comment)

If/when you send this to the TAG, I'm sure the TAG will give you the same feedback (speaking as a TAG Member).

And also, if you all are interested on getting any implementer on board (i.e., WebKit/Safari), I'd also encourage on scaling this back. I'd be surprised if Mozilla doesn't give you the exact same feedback, but they can speak for themselves.

@marcoscaceres
Copy link
Author

marcoscaceres commented Dec 2, 2025

@LiaHiscock, sorry, just a little bit more WICG context (speaking as ex-chair of the WICG). The presumption on which we (standard community) had consensus to move this to WICG was on implementer interest expressed at TPAC. Though I'm sympathetic to "we've received from partners remains overwhelmingly clear that cross origin installation is the valuable part of our install efforts", the "we've" and "our" might only be representative of Microsoft's position, not the larger community at large.

With my WebKit hat on, WebKit is opposed to cross-origin installation for the same reasons the W3C TAG already gave. As such, we would like to see all that stuff removed from the proposal; hence this pull request - which broadly captures what we have consensus on and sets out to solve the problem outlined in the Explainer:

"Today, the process of initiating an installation flow is somewhat fragmented; each user agent has created a set of entry points, some more discoverable and intuitive than others."

Let's exclusively focus on that - which is what this PR covers.

Happy to jump on a call to discuss.

@diekus
Copy link

diekus commented Dec 2, 2025

Hola Marcos, I am not sure that's the consensus this was moved to WICG. From feedback in the TAG review, it was advised that same-document installs would go towards the WebApps WG (there's an open PR for that), and background-document installs would go to further incubation and discussion in WICG (Precisely this document what we're doing here).

Since then there is WebApps WG has agreed there is a need for the (same-origin) capability (yay!) and there's the <install> proposal and there's currently an Origin Trial for the n.install method to gather feedback from developers as well.

I'd like to clarify that when Lia mentions that we've received feedback from that the cross origin installation is the valuable part of the install efforts, this comes from the broader developer community, and we're trying to represent their needs as best as possible. I'm sure that as a ex co-chair of WICG you can understand the enthusiasm to incubate these type of efforts.

Regarding the TAG feedback on #946, around centralization, diminished user agency and privacy implications are things we have addressed (for example by removing the install_sources field and looking into the declarative option). Happy to jump on a call and review your concerns as there has been lots of changes since you lovely Webkit folks looked at this.

I don't think it's particularly bad to incubate the work on background-document installations, and I think that's what WICG is for. The current-document discussions is happening in the open PR in WebApps. That was the recommendation from TAG and why we are proceeding this way.

Maybe we can get more broader feedback from developers to help navigate this situation? Would that help?

@marcoscaceres
Copy link
Author

marcoscaceres commented Dec 3, 2025

Hola Marcos, I am not sure that's the consensus this was moved to WICG. From feedback in the w3ctag/design-reviews#1051 (comment), it was advised that same-document installs would go towards the WebApps WG (there's an open w3c/manifest#1175 for that),

Right, which we are intending to close in favor of this incubation. @christianliebel, can also confirm. We (Web Apps WG) absolutely do not want multiple ways of doing the same thing.

and background-document installs would go to further incubation and discussion in WICG (Precisely this document what we're doing here).

If that is the case, we should rename this repository "cross-origin-background-page-install" or something and remove the following from the Explainer:

"Today, the process of initiating an installation flow is somewhat fragmented; each user agent has created a set of entry points, some more discoverable and intuitive than others."

If that is not the primary use case or the purpose of this incubation, we should then have a separate repository or we will just do the <install> button for the use case above. There is zero interest on the WebKit side for incubating "background-document installs", cross-origin installs, or Chromium specific stuff.

I don't think it's particularly bad to incubate the work on background-document installations, and I think that's what WICG is for. The current-document discussions is happening in the open PR in WebApps. That was the recommendation from TAG and why we are proceeding this way.

I think you've misunderstood that TAG's feedback (speaking as the primary author of it): we weren't saying "standardize the API", we were saying "figure out how to address the use case" (be it declarative or imperative) "without the cross-origin stuff" (same as WebKit's position). When the TAG gave the original feedback, the <install> proposals did not exist.

If/when you bring this proposal to the TAG we would again tell you the same thing: standardizing two solutions doesn't make sense: Pick one (and again remove with the cross-origin stuff).

I understand that there's interest from the "broader developer community", but if we can't get agreement on the fundamentals, and folks here ignore direct feedback from a potential implementer, then this will be yet another WICG incubation that never become part of a W3C standard.

My recommendation would be to get agreement on what use cases implementers are actually willing to work on. My recommendation would be to limit this to:

"The process of initiating an installation flow is somewhat fragmented; each user agent has created a set of entry points, some more discoverable and intuitive than others."

And that's it. Hope that makes sense.

@christianliebel
Copy link

christianliebel commented Dec 4, 2025

I think there are three levels of "web install". Here’s my understanding of the situation (correct me if I’m wrong):

Level Proponent/developer interest TAG feedback Cross-vendor interest
1. Same-document installs 👍 👍 👍
2. Same-origin (background-document) installs 👍 👍 👎
3. Cross-origin installs 👍 👎 👎

I agree that from the WebApps WG side, we are looking for one approach (declarative or imperative) that works well across all platforms (with their various install mechanisms).

The vendor feedback I received during TPAC (from Google, Mozilla, and Apple) was that they are more interested in exploring a declarative proposal. Microsoft and I (as a developer) would have preferred the imperative one.

The result of our TPAC discussion was:

Let's give ourselves a month to come up with an element proposal, run it internally to see if people are interested.

I suggest creating a "level 1" spec which can be adopted by the WebApps WG (or added to the Web App Manifest spec), while being extensible to make web installs of level 2 and 3 possible, and specify them in a separate document. This way, hopefully, everybody is satisfied. 😊

I think this can be done, as long as the levels are feature-detectible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants