- From: Alex Russell <notifications@github.com>
- Date: Thu, 12 Sep 2024 10:42:22 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/946/2346884312@github.com>
There seems to be some confusion in this thread. Some folks seem to be conflating browser-facilitated prompting based on browser quality signals with user-initiated flows that come from browser UI. Browsers that support browser-facilitated prompting have long required quality gates, including conformant manifests. The proposal here is explicitly to extend that system to cross-origin prompting. Browsers that don't provide any sort of developer-facilitated and controlled prompting are a long way from getting any value from `navigator.install()`, and my suggestion would be that they start by implementing the `onbeforeinstallprompt` analogue for ["Smart Banners" ](https://developer.apple.com/documentation/webkit/promoting_apps_with_smart_app_banners) (which require a great deal of developer work, including a stable ID) based on explicit developer signals and quality gates; manifests are a good first-step there. It only really makes sense for browsers that support developers in promoting their web apps on the same origin to extend that support to cross-origin cases with `navigator.install()`. Hopefully the TAG can recognise that the UI differences between browser-enhanced promotion and user-initiated, buried UI surfaces material to the success of install rates (as has been continually proven in PWA-supporting browser's data) and therefore categorically different in developer intent and need for API surface area. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/946#issuecomment-2346884312 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/946/2346884312@github.com>
Received on Thursday, 12 September 2024 17:42:26 UTC