- From: Matt Giuca <notifications@github.com>
- Date: Wed, 31 Jan 2018 03:34:48 +0000 (UTC)
- To: w3c/payment-handler <payment-handler@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 31 January 2018 03:35:13 UTC
I'm not 100% on this being an "anti-pattern". There's a delicate balance between declarative registration (let the user agent ask when to prompt the user) and programmatic. For what it's worth, I think we will be going this way on the other handler types: - registerProtocolHandler is a programmatic API in the style of requestPermission, but I think we will move to a world where RPH is treated as a declaration, silently "registering" the handler in the background (not as the default), then at a later time we can present registered handlers to the user. - Web Share Target will be declaratively specified in the manifest. As with RPH, when we encounter such a site, it is silently registered in the background. On the other hand, we tried this model with web app installation (the user agent can determine when to show an install prompt) and developers really did not like it. We have been moving ever closer to a programmatic API ([BeforeInstallPromptEvent.prompt](https://www.w3.org/TR/appmanifest/#prompt-method)) where the developer chooses when to show the prompt. So, maybe we should not so hastily remove requestPermission. Instead, it could be taken like registerProtocolHandler as a silent background registration that does not explicitly prompt the user. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/payment-handler/issues/246#issuecomment-361813420
Received on Wednesday, 31 January 2018 03:35:13 UTC